On 2024-04-25 10:06, Qing Zhao wrote:
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
Sorry I
On 2024-03-29 12:07, Qing Zhao wrote:
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
*
On 2024-03-18 12:28, Qing Zhao wrote:
This should probably bail out if object_size_type & OST_DYNAMIC == 0.
Okay. Will add this.
When add this into access_with_size_object_size, I found some old bugs
in early_object_sizes_execute_one, and fixed them as well.
Would you be able to isolate
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
*
On 2024-02-16 14:47, Qing Zhao wrote:
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
On 2024-02-16 14:47, Qing Zhao wrote:
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as
On 2024-02-12 10:00, Richard Biener wrote:
GCC driver support is then to the extent identifying the inputs and the outputs.
We already have -MM to generate a list of non-system dependencies, so
gcc should be able to pass on inputs to the tool, which could then map
those files (and the system
On 2024-02-12 08:16, Martin Jambor wrote:
This probably ties in somewhat with an idea David Malcolm had riffed on
with me earlier, of caching files for diagnostics. If we could unify
file accesses somehow, we could make this happen, i.e. open/read files
as root and then do all execution as
On 2024-02-09 15:06, Joseph Myers wrote:
Ideally dependencies would be properly set up so that everything is built
in the original build, and ideally there would be no need to relink at
install time (I'm not sure of the exact circumstances in which it might be
needed, or on what OSes to e.g.
On 2024-02-09 12:14, Joseph Myers wrote:
On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:
For privilege management we could add a --allow-root driver flag that allows
gcc to run as root. Without the flag one could either outright refuse to run
or drop privileges and run. Dropping privileges
On 2024-02-09 10:38, Martin Jambor wrote:
If anyone is interested in scoping this and then mentoring this as a
Google Summer of Code project this year then now is the right time to
speak up!
I can help with mentoring and reviews, although I'll need someone to
assist with actual approvals.
On 2023-12-18 09:35, Siddhesh Poyarekar wrote:
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, t
On 2023-12-20 00:23, Jeff Law wrote:
On 12/19/23 10:21, Siddhesh Poyarekar wrote:
Narrow down scope of the unknowns bitmap so that it is only accessible
within the reexamination process. This also removes any role of unknown
propagation from object_sizes_set, thus simplifying that code path
On 2023-12-19 17:57, Jakub Jelinek wrote:
On Mon, Dec 18, 2023 at 11:42:52AM -0500, Siddhesh Poyarekar wrote:
It is always safe to set the computed bit for dynamic object sizes at
the end of collect_object_sizes_for because even in case of a dependency
loop encountered in nested calls, we have
UNKNOWNS.
Drop all references to it.
(object_sizes_set): Move unknowns propagation code to...
(gimplify_size_expressions): ... here. Also free reexamine
bitmap.
(propagate_unknowns): New parameter UNKNOWNS. Update callers.
Signed-off-by: Siddhesh Poyarekar
/113012
* tree-object-size.cc (compute_builtin_object_size): Expand
comment for dynamic object sizes.
(collect_object_sizes_for): Always set COMPUTED bitmap for
dynamic object sizes.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- Bootstrapped x86_64 and config=ubsan
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, the absence of hardening does not make a
program any more
On 2023-12-07 10:42, Eric Botcazou wrote:
I think from a language standpoint, the general idea that nested
functions are just any functions inside functions (which is how the C
nested functions essentially behave) is too broad and they should be
restricted to minimal implementations that, e.g.
On 2023-12-06 09:41, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 09:30:32AM -0500, Siddhesh Poyarekar wrote:
We have the -Wmemset-transposed-args warning, couldn't we
have a similar one for calloc, and perhaps do it solely in
the case where one uses sizeof of the type used in the cast
pointer
On 2023-12-06 09:21, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
Further I think
"size less than or equal to the size requested"
is quite ambiguous in the calloc case, isn't the size requested in the
calloc case actually nmemb * size rather than just
On 2023-12-04 16:31, Martin Uecker wrote:
If (assuming from them being called lambdas) they are primarily for
small functions without side-effects then it's already a significantly
stronger specification than what we have right now with C nested
functions. That would end up enforcing what you
On 2023-12-04 13:51, Jakub Jelinek wrote:
Why? The syntax doesn't seem to be something unexpected, and as C doesn't
have lambdas, one can use the nested functions instead.
The only problem is if you need to pass function pointers somewhere else
(and target doesn't have function descriptors or
On 2023-12-04 13:48, Martin Uecker wrote:
I empathize with Jakub's stated use case though of keeping the C
frontend support for testing purposes, but that could easily be done
behind a flag, or by putting nested C func deprecation behind a flag.
I am relatively sure C will get some form of
[Branching this into a separate conversation to avoid derailing the
patch, which isn't directly related]
On 2023-12-04 12:21, Martin Uecker wrote:
I do not really agree with that. Nested functions can substantially
improve code quality and in C can avoid type unsafe use of
void* pointers in
On 2023-12-04 11:39, Andreas Schwab wrote:
On Dez 04 2023, Siddhesh Poyarekar wrote:
For hardened code in C, I think we really should look to step away from
nested functions instead of adding ways to continue supporting it. There's
probably a larger conversation to be had about the utility
On 2023-12-02 04:42, Martin Uecker wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack. Therefore the following patch
adds -Werror=trampolines to -fhardened.
This
On 2023-11-02 10:12, Martin Uecker wrote:
This shouldn't be necessary. The object-size pass
can track pointer arithmeti if it comes after
inserting the .ACCESS_WITH_SIZE.
https://godbolt.org/z/fvc3aoPfd
The problem is dependency tracking through the pointer arithmetic, which
Jakub suggested
On 2023-10-31 12:26, Qing Zhao wrote:
Hi,
I wrote a summary based on our extensive discussion, hopefully this can be
served as an informal proposal.
Please take a look at it and let me know any comment or suggestion.
There are some (???) in the section 3.2 and 3.6, those are my questions
On 2023-10-28 16:29, Martin Uecker wrote:
Isn't this testcase h() in builtin-dynamic-object-size-20.c? If you're
referring to testcase i(), then maybe "where the size is given by a
non-trivial function of a function parameter, e.g.
fn (size_t n, char buf[dummy(n)])."
h() is supported. For
On 2023-10-26 04:37, Martin Uecker wrote:
Hi Sid and Jakub,
here is the patch discussed in PR 109334.
I can't approve, but here's a review:
Martin
tree-optimization/109334: Improve computation for access attribute
The fix for PR104970 restricted size computations to
On 2023-10-25 09:27, Qing Zhao wrote:
On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
On 2023-10-24 18:51, Qing Zhao wrote:
Thanks for the proposal!
So what you suggested is:
For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
then the call to the _bdos
On 2023-10-25 04:16, Martin Uecker wrote:
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
Am 24.10.2023 um 22:38 schrieb Martin Uecker :
Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
Hi, Sid,
Really appreciate for your example and detailed explanation.
On 2023-10-24 18:51, Qing Zhao wrote:
Thanks for the proposal!
So what you suggested is:
For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
then the call to the _bdos (x.buf, 1) will
Become:
_bdos(__builtin_with_size(x.buf, x.L), 1)?
Then the implicit use of x.L
On 2023-10-24 18:41, Qing Zhao wrote:
On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
On 2023-10-24 16:38, Martin Uecker wrote:
Here is another proposal: Add a new builtin function
__builtin_with_size(x, size)
that return x but behaves similar to an allocation
function in that BDOS can look at the size argument
to discover the size.
The FE insers this function when the field
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
of the object, As a result, the TYPE info and the attached counted_by info of
the object can NOT be
On 2023-10-23 15:43, Qing Zhao wrote:
On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote:
On 2023-10-23 14:06, Martin Uecker wrote:
We should aim for a good integration with the BDOS pass, so
that it can propagate the information further, e.g. the
following should work:
struct { int L
On 2023-10-23 14:06, Martin Uecker wrote:
We should aim for a good integration with the BDOS pass, so
that it can propagate the information further, e.g. the
following should work:
struct { int L; char buf[] __counted_by(L) } x;
x.L = N;
x.buf = ...;
char *p = >f;
__bdos(p) -> N
So we need to
On 2023-10-23 08:34, Richard Biener wrote:
A related issue is that assignment to the field and storage allocation
are not tied together - if there's no use of the size data we might
remove the store of it as dead.
Maybe the trick then is to treat the size data as volatile? That ought
to
On 2023-10-23 03:57, Richard Biener wrote:
On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
On 2023-10-20 14:38, Qing Zhao wrote:
How about the following:
Add one more parameter to __builtin_dynamic_object_size(), i.e
On 2023-10-20 14:38, Qing Zhao wrote:
How about the following:
Add one more parameter to __builtin_dynamic_object_size(), i.e
__builtin_dynamic_object_size (_1,1,array_annotated->foo)?
When we see the structure field has counted_by attribute.
Or maybe add a barrier preventing any
[Sorry, I forgot to respond to this]
On 2023-10-06 16:01, Martin Uecker wrote:
Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
On 2023-10-06 01:11, Martin Uecker wrote:
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM
On 2023-10-18 10:51, Qing Zhao wrote:
+ member FIELD_DECL is a valid field of the containing structure's fieldlist,
+ FIELDLIST, Report error and remove this attribute when it's not. */
+static void
+verify_counted_by_attribute (tree fieldlist, tree field_decl)
+{
+ tree attr_counted_by
On 2023-10-06 01:11, Martin Uecker wrote:
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
2. How would you handle signedness of the size field? The size gets
converted to sizetype everywhere it is used
On 05-Oct-2023 18:35, Kees Cook wrote:On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
> 2. How would you handle signedness of the size field? The size gets
> converted to sizetype everywhere it is used and overflows/underflows may
> produce interesting results
On 2023-08-25 11:24, Qing Zhao wrote:
This is the 3rd version of the patch, per our discussion based on the
review comments for the 1st and 2nd version, the major changes in this
version are:
Hi Qing,
I hope the review was helpful. Overall, a couple of things to consider:
1. How would you
On 2023-08-25 11:24, Qing Zhao wrote:
Use the counted_by atribute info in builtin object size to compute the
subobject size for flexible array members.
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
*
On 2023-10-05 14:51, Siddhesh Poyarekar wrote:
On 2023-08-25 11:24, Qing Zhao wrote:
Provide a new counted_by attribute to flexible array member field.
The obligatory "I can't ack the patch but here's a review" disclaimer :)
'counted_by (COUNT)'
The 'counted_by' att
On 2023-08-25 11:24, Qing Zhao wrote:
Provide a new counted_by attribute to flexible array member field.
The obligatory "I can't ack the patch but here's a review" disclaimer :)
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the flexible array
member of a
Committed some trivial comma and indentation fixups that Jan shared with
me off-list.
Jan Engelhardt (2):
secpol: add grammatically missing commas / remove one excess instance
secpol: consistent indentation
SECURITY.txt | 48
1 file changed,
From: Jan Engelhardt
86% of the document have 4 spaces; adjust the remaining 14%.
Signed-off-by: Jan Engelhardt
ChangeLog:
* SECURITY.txt: Fix up indentation.
---
SECURITY.txt | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git
From: Jan Engelhardt
Signed-off-by: Jan Engelhardt
ChangeLog:
* SECURITY.txt: Fix up commas.
---
SECURITY.txt | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/SECURITY.txt b/SECURITY.txt
index b65f24cfc2a..93792923583 100644
--- a/SECURITY.txt
+++
On 2023-10-04 11:49, Alexander Monakov wrote:
On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Some typos and wording suggestions below.
I've incorporated all your and David's suggestions
Ping!
On 2023-09-28 07:55, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
SECURITY.txt | 205 +++
1 file changed, 205 insertions
On 2023-09-28 12:55, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
Sorry I forgot to summarize changes since the previous version:
- Reworded the introduction so
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
SECURITY.txt | 205 +++
1 file changed, 205 insertions(+)
create mode 100644 SECURITY.txt
diff --git
On 2023-09-20 08:29, Jakub Jelinek wrote:
I just noticed (ENOCOFFEE) that the line (after removing libvtv) is:
Support libraries such as libiberty, libcc1 and libcpp have been
developed separately to share code with other tools such as binutils
and gdb.
Does that address your
On 2023-09-20 07:58, Siddhesh Poyarekar wrote:
On 2023-09-20 07:55, Jakub Jelinek wrote:
On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote:
+ Support libraries such as libiberty, libcc1 libvtv and libcpp have
Missing comma before libvtv. But more importantly, libvtv
On 2023-09-20 07:55, Jakub Jelinek wrote:
On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote:
+Support libraries such as libiberty, libcc1 libvtv and libcpp have
Missing comma before libvtv. But more importantly, libvtv is not
support library like libiberty, libcpp
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
Sending as a proper patch since there have been no further comments on
the RFC. I toyed with the idea of making the distinction of
"exploitable vulnerab
On 2023-09-12 11:25, Richard Sandiford via Gcc-patches wrote:
This series of patches fixes deficiencies in GCC's -fstack-protector
implementation for AArch64 when using dynamically allocated stack space.
This is CVE-2023-4039. See:
While this is a legitimate missed hardening, I'm not sure if
Hello folks,
Here's v3 of the top part of the security policy. Hopefully this
addresses all concerns raised so far.
Thanks,
Sid
What is a GCC security bug?
===
A security bug is one that threatens the security of a system or
network, or might compromise the
On 2023-08-17 17:25, Qing Zhao wrote:
It's not exactly the same issue, the earlier discussion was about choosing sizes in the
same pass while the current one is about choosing between passes, but I agree it
"rhymes". This is what I was alluding to originally (for OST_MINIMUM use
MIN_EXPR if
On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise information
than the later phase, we should use its result if it’s NOT UNKNOWN?
We can't be sure about that though, can we? For example for something like
this:
struct S
{
int a;
On 2023-08-17 15:27, Qing Zhao wrote:
Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
sure if that's the case for maximum size though, my gut says it isn't.
So, the major purpose for adding the
On 2023-08-17 09:58, Qing Zhao wrote:
So this is a (sort of) known issue, which necessitated the early_objsz pass to
get an estimate before a subobject reference was optimized to a MEM_REF.
Do you mean that after a subobject reference was optimized to a MEM_REF, there
is no way to compute
On 2023-08-16 11:59, Qing Zhao wrote:
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void
On 2023-08-16 11:06, Alexander Monakov wrote:
No I understood the distinction you're trying to make, I just wanted to point
out that the effect isn't all that different. The intent of the wording is
not to prescribe a solution, but to describe what the compiler cannot do and
hence, users must
On 2023-08-15 19:07, Alexander Monakov wrote:
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
Thanks, this is nicer (see notes below). My main concern is that we
shouldn't pretend there's some method of verifying that arbitrary source
code is "safe" to pass to an unsandboxed com
On 2023-08-16 04:25, Alexander Monakov wrote:
On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote:
I'd prefer to reword this, as libgccjit was a poor choice of name for
the library (sorry!), to make it clearer it can be used for both ahead-
of-time and just-in-time compilation, and that
On 2023-08-15 10:07, Alexander Monakov wrote:
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitrary source
On 2023-08-14 19:12, Qing Zhao wrote:
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p =
On 2023-08-15 01:59, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
There's no practical (programmatic) way to do such validation; it has to be a
manual audit, which is why source code passed to the compiler has to be
*trusted*.
No, I do not think that is a logical
On 2023-08-14 17:16, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
1. It makes it clear to users of the project the scope in which the project
could be used and what safety it could reasonably expect from the project. In
the context of GCC for example, it cannot
On 2023-08-14 14:51, Richard Sandiford wrote:
I think it would help to clarify what the aim of the security policy is.
Specifically:
(1) What service do we want to provide to users by classifying one thing
as a security bug and another thing as not a security bug?
(2) What service do we
Hi,
Here's the updated draft of the top part of the security policy with all
of the recommendations incorporated.
Thanks,
Sid
What is a GCC security bug?
===
A security bug is one that threatens the security of a system or
network, or might compromise the
On 2023-08-11 11:12, David Edelsohn wrote:
The text above states "bugs in these libraries may be evaluated for
security impact", but there is no comment about the criteria for a
security impact, unlike the GLIBC SECURITY.md document. The text seems
to imply the "What is a security bug?"
On 2023-08-11 11:09, Paul Koning wrote:
On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code.
I think this leaves open the interpretation "every wrong cod
On 2023-08-10 14:28, Richard Sandiford wrote:
Siddhesh Poyarekar writes:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David
On 2023-08-10 12:39, Jakub Jelinek wrote:
On Thu, Aug 10, 2023 at 12:30:06PM -0400, Siddhesh Poyarekar wrote:
The definition of __bos/__bdos allows us the freedom to *estimate* rather
than be precise, so I'd go for sizeof(x) + N * sizeof(*x.a) since it's bound
to give the more conservative
On 2023-08-10 11:18, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 10:58 -0400 schrieb Siddhesh Poyarekar:
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
Am
On 2023-08-09 14:17, David Edelsohn wrote:
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
>> Do you have a suggestion for the language to address libgcc,
>> libstdc+
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including the
runtime
On 2023-08-08 11:48, David Malcolm wrote:
On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote:
On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-
patches wrote:
There's probably external tools
On 2023-08-08 10:37, Jakub Jelinek wrote:
On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc, libstdc++,
etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
BTW, I think we should
On 2023-08-08 10:14, David Edelsohn wrote:
On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:04, Richard Biener wrote:
> On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote:
>&g
On 2023-08-08 10:04, Richard Biener wrote:
On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote:
On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote:
There's probably external tools to do this,
On 2023-08-08 04:16, Richard Biener wrote:
On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches
wrote:
FOSS Best Practices recommends that projects have an official Security
policy stated in a SECURITY.md or SECURITY.txt file at the root of the
repository. GLIBC and Binutils have
On 2023-08-04 15:06, Qing Zhao wrote:
Yes, that's what I'm thinking.
so `q` must be pointing to a single element. So you could deduce:
1. the minimum size of the whole object that q points to.
You mean that the TYPE will determine the minimum size of the whole object?
(Does this include
On 2023-08-04 11:27, Qing Zhao wrote:
On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular
fixed size array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH];
};
…
int main ()
{
struct fix *p;
p =
On 2023-08-03 12:43, Qing Zhao wrote:
Surely we could emit that for __bdos(q->array, 0) though, couldn't we?
For __bdos(q->array, 0), we only have the access info for the sub-object q->array,
we can surely decide the size of the sub-object q->array, but we still cannot
decide the whole
On 2023-08-02 10:02, Qing Zhao wrote:
/*when checking the observed access p->array, we only have info on the
observed access, i.e, the TYPE_SIZE info from the access. We don't have
info on the whole object. */
expect(__builtin_dynamic_object_size(q->array, 1), q->foo *
On 2023-08-01 18:57, Kees Cook wrote:
return p;
}
/* in the following function, malloc allocated less space than size of the
struct fix. Then what's the correct behavior we expect
the __builtin_object_size should have for the following?
*/
static struct fix * noinline
1 - 100 of 377 matches
Mail list logo
