Re: [PATCH] Build libc-start with stack protector for SHARED

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2/12/21 6:26 AM, Siddhesh Poyarekar via Libc-alpha wrote:
> On 2/12/21 12:55 AM, Adhemerval Zanella wrote:
>>
>>
>> On 03/02/2021 02:42, Siddhesh Poyarekar via Libc-alpha wrote:
>>> This does not change the emitted code since __libc_start_main does not
>>> return, but is important for formal flags compliance.
>>>
>>> This also cleans up the cosmetic inconsistency in the stack protector
>>> flags in csu, especially the incorrect value of STACK_PROTECTOR_LEVEL.
>>
>> I am seeing the following regressions with --enable-stack-protector=all
>> on x86_64 and i686 (I haven't seen is on powerpc64le-linux-gnu):
>>
>> FAIL: elf/ifuncmain9picstatic
>> FAIL: elf/ifuncmain9static
>> FAIL: elf/tst-ifunc-isa-1-static
>> FAIL: elf/tst-ifunc-isa-2-static
>>
>> $ gdb ./elf/ifuncmain9picstatic
>> [...]
>> (gdb) r
>> [...]
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000401944 in resolver () at ifuncmain9.c:47
>> 47      {
>> (gdb) bt
>> #0  0x0000000000401944 in resolver () at ifuncmain9.c:47
>> #1  0x0000000000402e88 in elf_ifunc_invoke (addr=<optimized out>) at 
>> ../sysdeps/x86_64/dl-irel.h:44
>> #2  elf_irela (reloc=0x4004f0) at ../sysdeps/x86_64/dl-irel.h:44
>> #3  apply_irel () at ../csu/libc-start.c:86
>> #4  __libc_start_main (main=0x401690 <main>, argc=1, 
>> argv=0x7fffffffd808, init=0x403cd0 <__libc_csu_init>, fini=0x403d60 
>> <__libc_csu_fini>, rtld_fini=0x0, stack_end=0x7fffffffd7f8) at 
>> ../csu/libc-start.c:206
>> #5  0x00000000004017ba in _start () at ../sysdeps/x86_64/start.S:120
>>
>> (gdb) disas
>> Dump of assembler code for function resolver:
>>     0x0000000000401940 <+0>:     sub    $0x18,%rsp
>> => 0x0000000000401944 <+4>:     mov    %fs:0x28,%rax
>> (gdb) i r fs
>> fs             0x0                 0
>>
>> It seems we need to setup the thread pointer earlier.
>>
> 
> I wasn't able to reproduce this until I repeated the build from scratch. 
>   Sorry, I'll take a look at this again.  Thanks for checking.

... and now I see these failures all the way back to 2.33 tag and 2 out 
of the 4 failures all the way back to 2.32.  memusagestat (of all 
things!) prevented my build from completing on Fedora 33 because it 
needs 2.32 symbols that it couldn't find during the build.

I'll work on detangling this and figuring out the root cause soon.

Siddhesh