[llvm] r221150 - Emit .eh_frame with relocations to functions, rather than sections
Cary Coutant
ccoutant at google.com
Tue Nov 4 14:22:35 PST 2014
> * The interpretation of the ELF standard seems correct to me. That is,
> both gcc+gas and clang have a bug according to the spec since they
> produce a relocation to a local symbol from outside of the comdat.
> * The .eh_frame seems to have magical treatment in gold and bfd ld.
> They will not warn on:
>
> .section .text.foo,"axG", at progbits,foo,comdat
> .Local:
> nop
> .section .eh_frame
> // .section .zed
> .long .Local
>
> but will warn if the section is .zed instead of .eh_frame.
Yes, both linkers give special treatment to the .eh_frame section. If
you have an .eh_frame section with a relocation to a discarded COMDAT
section, the linker will simply discard that FDE automatically. Thus
it works in spite of the "malformed" ELF. If the .eh_frame section
were malformed, however, the linker would give up on optimizing it,
and would treat it as an ordinary section. In that case, you'll get an
error.
> * The correct way of handling this according to the spec would
> probably be to have one .eh_frame in each comdat:
>
> .section .text.foo,"axG", at progbits,foo,comdat
> .Local1:
> nop
> .section .eh_frame,"G", at progbits,foo,comdat
> .long .Local1
> .section .text.bar,"axG", at progbits,bar,comdat
> .Local2:
> nop
> .section .eh_frame,"G", at progbits,bar,comdat
> .long .Local2
>
> Unfortunately, this causes gold to crash when run with
>
> ld -shared -o test.so test.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtendS.o
Hmmm. Yes, that would be a bug. At least with .eh_frame sections,
there's no real need to do this.
-cary
More information about the llvm-commits
mailing list