Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm 2. cd llvm 3. ./configure \ --disable-static \ --enable-assertions \ --enable-debug-runtime \ --enable-jit \ --enable-optimized \ --enable-shared \ --enable-targets=host-only \ --with-pic \ --enable-pic \ --disable-binding 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 Additional info:
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.