[PATCH] Fix section type of .eh_frame on Linux x86_64

[Adhemerval Zanella]

On 13/03/2020 10:12, H.J. Lu wrote:
> On Fri, Mar 13, 2020 at 5:28 AM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>
>>
>> On 11/03/2020 18:27, Fangrui Song via Libc-alpha wrote:
>>> Clang since https://reviews.llvm.org/D73999 will error for the wrong
>>> sh_type.
>>
>> It will make eh_frame section of sigaction object to have the
>> SHT_X86_64_UNWIND, but it seems that 'ld.bfd' at least ignore and
>> set the resulting eh_frame sh_type for libc.so to SHT_PROGBITS
>> anyway. The 'as' also still generate SHT_PROGBITS for code that
>> requires a eh_frame (C++ with exception handling that emits a
>> gcc_except_table section, for instance).
> 
> SHT_X86_64_UNWIND was added so that linker can group all
> SHT_X86_64_UNWIND sections together without checking
> .eh_frame section name.   Other than that, linker treats .eh_frame like
> other SHT_PROGBITS sections.   Since .eh_frame is also listed as a
> special section, similar to .got and .plt, SHT_X86_64_UNWIND isn't
> really required.

Thanks for the explanation.

> 
>> Setting the eh_frame in assembly routines is not a common practice,
>> the only other code that I could find that actually does it is
>> Linux.  For i686 vDSO is also uses 'progbits':
>>
>> arch/x86/entry/vdso/vdso32/sigreturn.S
>>
>>  36         .section .eh_frame,"a",@progbits
>>  37 .LSTARTFRAMEDLSI1:
>>
>> The change should be ok, but I would like to understand better why
>> exactly SHT_X86_64_UNWIND should be used for eh_frame, why binutils
>> does not seems to use it to eh_frame, and why clang is now not
>> accepting the eh_frame with SHT_PROGBITS type.
>>
> 
> Linker should check .eh_frame section name, and optionally check
> SHT_X86_64_UNWIND.   Because of this, i386 psABI only specifies
> special .eh_frame section without SHT_386_UNWIND.
> 
> So I think there is no need to change glibc and lld should be changed.
> 

I was confused why binutils was not throwing a similar issue.  So
the idea is SHT_X86_64_UNWIND is optional on eh_frame definitions,
not mandatory, and being optional I agree that compiler/linker
should not emit an error in such case.