[llvm] r221150 - Emit .eh_frame with relocations to functions, rather than sections

[Cary Coutant]

> * 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