[PATCH] Enable _FORTIFY_SOURCE=3 for gcc 12 and above

Siddhesh Poyarekar siddhesh@sourceware.org
Fri Dec 17 15:24:36 GMT 2021


On 12/17/21 19:24, Siddhesh Poyarekar wrote:
> On 12/17/21 18:47, Adhemerval Zanella wrote:
>> On 17/12/2021 01:07, Siddhesh Poyarekar via Libc-alpha wrote:
>>> gcc 12 now has support for the __builtin_dynamic_object_size builtin.
>>> Adapt the macro checks to enable _FORTIFY_SOURCE=3 on gcc 12 and above.
>>>
>>> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
>>
>> With gcc version 12.0.0 20211217 (experimental) [master 
>> r12-6038-g411ac94611f]
>> I am seeing two new failures:
>>
>>    FAIL: debug/tst-chk7
>>    FAIL: debug/tst-chk8
>>
>> And both explicit set _FORTIFY_SOURCE to 3.  I am not if is really 
>> related to
>> _FORTIFY_SOURCE=3:
>>
>> __GI_getenv (name=0x7ffff7f6ec25 "CPATH", name@entry=0x7ffff7f6ec23 
>> "LOCPATH") at get
>> env.c:84
>> 84                if (name_start == ep_start && !strncmp (*ep + 2, 
>> name, len)
>> (gdb) bt
>> #0  __GI_getenv (name=0x7ffff7f6ec25 "CPATH", 
>> name@entry=0x7ffff7f6ec23 "LOCPATH")
>>      at getenv.c:84
>> #1  0x00007ffff7dd87bc in __GI_setlocale (category=category@entry=6,
>>      locale=locale@entry=0x555555564195 "de_DE.UTF-8") at setlocale.c:252
>> #2  0x000055555555e956 in do_test ()
>>      at /home/azanella/Projects/glibc/glibc-git/debug/tst-chk1.c:1424
>> #3  0x0000555555562cd2 in support_test_main (argc=1, argv=0x7fffffffd810,
>>      config=config@entry=0x7fffffffd670) at support_test_main.c:415
>> #4  0x0000555555559bad in main (argc=<optimized out>, argv=<optimized 
>> out>)
>>      at ../support/test-driver.c:170
> 
> That looks unrelated but I'll take a look.  I've been testing with the 
> full __bdos patchset and that did not fail.

Sorry that was tardy of me; that's just the test failing to catch buffer 
overflows, which ends up corrupting state for later tests and 
eventually, getenv.  I should have anticipated that.

I'm basically trying to get the support in early in case the remaining 
gcc patches take longer and glibc 2.35 freezes over.  Should I xfail 
these tests for gcc for now and then revert that bit once the rest of 
the support goes in?  If it's not acceptable to push this change before 
all of the compiler support is in, then I'll settle for the possibility 
of having to wait until 2.36 development opens and then backport the 
change to 2.35.

What would you suggest?

Thanks,
Siddhesh


More information about the Libc-alpha mailing list