https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the early objsz pass, I'm afraid it can have security implications.
Artificial testcase:
extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
__attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__nonnull__ (1, 2)));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) char *
__attribute__ ((__nothrow__ , __leaf__)) strcpy (char *__restrict __dest, const
char *__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 > 1));
}
const char *str1 = "JIHGFEDCBA";
int
main ()
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = a.buf1;
char *q = p + 1;
char *r = q + 3;
char *t = r;
if (r != &a.buf1[4])
t = (char *) &a;
strcpy (t, str1 + 5);
return 0;
}
with the early objsz this will use 10 for __bos rather than 5, so will not
detect the buffer overflow.
So, if we want to go forward with that, perhaps:
1) the first instance should (also for performance reasons) only try to deal
with __bos calls where the second argument is 1 or 3, and leave 0 and 2 alone
for the second objsz pass
2) maybe instead of folding the __bos call into constant, it should turn it
into
MIN_EXPR <__bos, XX> where XX would be the value computed by the pass (for
__bos (, 3) MAX_EXPR). That way, we'd use the smaller value of the two passes.
