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

[Rafael Espíndola]

CCing a linker expert to check if the diagnostic is correct (and maybe
a bug report :-) )

First, on the patch itself: There is no requirement on what the symbol
type is when a .cfi_startproc is used. In fact, it can be used with a
local symbol or no symbol present, so tracking the "current symbol"
doesn't look like a viable solution.

Some additional observations:

* The comment about avoiding the relocation is probably a MachO only
thing, where the linker is expected to parse the section and know what
it is.
* GCC (+gas) has the same problem.

Compiling

template <typename T> void f() {}
template <typename T> void g() {}
template void f<int>();
template void g<int>();

I get

Relocation section '.rela.eh_frame' at offset 0x2c0 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000020  000500000002 R_X86_64_PC32     0000000000000000
.text._Z1fIiEvv + 0
000000000034  000600000002 R_X86_64_PC32     0000000000000000
.text._Z1gIiEvv + 0

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

* 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

Cheers,
Rafael