Red Hat Bugzilla – Bug 458950
Corrupt eh_frame_hdr in LLVM
Last modified: 2009-01-27 10:16:55 EST
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
2. cd llvm
3. ./configure \
4. make VERBOSE=true
Actual results:/usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMExecutionEngine.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMJIT.o(.eh_frame); no .eh_frame_hdr table will be created.
Expected results:No error
It is a ld error:
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:
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;
Created attachment 314238 [details]
I will check it more if it should not optimize out such dead FDEs.
*** Bug 461675 has been marked as a duplicate of this bug. ***
binutils-22.214.171.124.6-6.fc9 has been submitted as an update for Fedora 9.
binutils-126.96.36.199.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-188.8.131.52.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
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++
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
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-184.108.40.206.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.