Bug 458950

It is a ld error:

These relocations
Relocation section '.rela.eh_frame' at offset 0x14b0 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000020  000600000002 R_X86_64_PC32     0000000000000000 .text._ZNK4llvm13Targe + 0

with its target section .text._ZNK4llvm13 which is SHT_GROUP
  [ 9] .text._ZNK4llvm13 PROGBITS         0000000000000000  000004c0
       000000000000004f  0000000000000000 AXG       0     0     16

get converted to:
000000000020  000000000000 R_X86_64_NONE                        0000000000000000

by this code:
../bfd/elf64-x86-64.c
      if (sec != NULL && elf_discarded_section (sec))
        {
          /* For relocs against symbols from removed linkonce sections,
             or sections discarded by a linker script, we just want the
             section contents zeroed.  Avoid any special processing.  */
          _bfd_clear_contents (howto, input_bfd, contents + rel->r_offset);
          rel->r_info = 0;
          rel->r_addend = 0;
          continue;
        }

Created attachment 314238 [details]
FIx.

I will check it more if it should not optimize out such dead FDEs.

Upstream post:
http://sourceware.org/ml/binutils/2008-09/msg00124.html

*** Bug 461675 has been marked as a duplicate of this bug. ***

binutils-2.18.50.0.6-6.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/binutils-2.18.50.0.6-6.fc9

binutils-2.18.50.0.6-6.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update binutils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8235

binutils-2.18.50.0.6-6.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

So I am now running:

[bradles@riggins:bradles-diss:1006]$ rpm -qa |grep binutils
binutils-2.18.50.0.6-6.fc9.x86_64

And when I link my executable, I still see this:

xml -lxml2 -ldl -lstdc++ -o bin/hecios_cmd
/usr/bin/ld: error in lib/inet.o(.eh_frame); no .eh_frame_hdr table will be created.

Additionally, I profiled my software, and exception handling is now a huge percentage of my runtime, even though I have to catch several frequently occurring exceptions, and then discard the thrown data entirely (i.e. a no op).  Not a good thing.

Here is my compiler collection:
[bradles@riggins:bradles-diss:1008]$ rpm -qa |grep c++
compat-libstdc++-296-2.96-140.i386
libsigc++20-2.2.2-1.fc9.x86_64
compat-libstdc++-33-3.2.3-63.x86_64
libstdc++-devel-4.3.0-8.i386
libstdc++-devel-4.3.0-8.x86_64
gcc-c++-4.3.0-8.x86_64
libstdc++-4.3.0-8.x86_64
compat-gcc-34-c++-3.4.6-9.x86_64
libstdc++-4.3.0-8.i386
compat-libstdc++-33-3.2.3-63.i386


I have tried performing the partial link of libinet.o both with and without --eh-frame-hdr as an argument to the partial link call to ld.

Unfortunately we can't do anything about Comment #8 because we can't
reproduce it.  Please create a test case and attach it to a new bug
report.

I already added the bug, you guys marked it as a dupe of this bug (check 46175 above).  Will you accept a big batch of binary stuff, as I have no idea what caused the bug?  Or if you prefer I can provide instructions that will require building my code's prerequisite packages.  It's all GPL I think, so shouldn't be any issues.

Everything was fine, then I upgraded to FC9, and suddenly the problem appeared.  I presume its related to me using prelinking with exceptions, but darn if I know.  I tried just creating a few files to see if it would appear, but that did not cause it.

If the problem still persists after you have the fix, we need to
re-open your bug.  We know that the original bug is fixed in
binutils-2.18.50.0.6-6.fc9.x86_64, so your bug must be unrelated.

With regard to reproducibility, the easier it is for a maintainer to
reproduce your bug the more likely it is to get fixed.  Anything you
can do to narrow the scope of the problem will help us.