Created attachment 8628 [details]
.cpp and .h files with a Makefile to reproduce
Hi. I've attached a small example reproducer for the problem, but essentially, we're using gold to perform a partial link on some objects, then when it comes to the final link, we see an error and no .eh_frame_hdr created.
g++ -c T.cpp
g++ -c c1.cpp
g++ -c c2.cpp
gold -r -o c.so T.o c1.o c2.o
g++ -c main.cpp
g++ -o a.out c.so main.o
/usr/bin/ld: error in c.so(.eh_frame); no .eh_frame_hdr table will be created.
We're not seeing the problem if we use ld for the partial link instead, but we'd like to keep using gold for the substantial speed increase.
Any help would be appreciated.
$ ld.gold -v
GNU gold (GNU Binutils for Debian 2.25) 1.11
Given Cary's blisteringly fast fix for Bug 19291 today, I wonder if there's something more we could do to help move this, our other gold issue, along. Perhaps our reproducer didn't work for Cary?
I suppose it might help someone to find their way to the source of their pain to mention that our motivation is more than just cosmetic: we've found that libunwind's stack trace generation can be slow in the absence of .eh_frame_hdr.
The same problem is present in the ToT gold.
A simpler test case. The input asm contains a single .init_array constructor in its own comdat.
$ cat 1.s
.p2align 4, 0x90
f: # @f
.size f, .Lfunc_end0-f
$ as 1.s -o 1.o
$ ld.gold -r -o full.o 1.o 1.o
$ ld.bfd -shared full.o -o libfull.so
ld: error in full.o(.eh_frame); no .eh_frame_hdr table will be created.
The resulting library has an empty (header-only) eh_frame_hdr:
12 .eh_frame_hdr 00000008 00000000000006b0 00000000000006b0 000006b0 2**2
If ld.gold is used instead of ld.bfd in the second link, then there is no error message, but the same end result.
The master branch has been updated by Cary Coutant <firstname.lastname@example.org>:
Author: Cary Coutant <email@example.com>
Date: Sun Mar 20 19:15:56 2016 -0700
Fix problem where gold cannot build .eh_frame_hdr from ld -r output.
When running ld -r on objects that have comdat groups, when gold
deduplicates a function in a comdat group, it removes the relocations
from the EH information that referred to the dropped copy of the function.
When running a final link using the result of the -r link, the missing
relocation cause it to fail to recognize the FDE for the dropped
This patch improves gold's FDE scanning to take into account the
possibility that an FDE corresponds to a dropped function, and drops
that FDE as well.
Gnu ld, on the other hand, leaves the relocations in the ld -r output,
but makes them R_NONE with an r_sym field of 0. This was sufficient to
let both linkers recognize the FDE properly.
With this fix, if you do an ld -r with gold, then do the final link with
Gnu ld, the .eh_frame_hdr section will not be generated. To make it work
with Gnu ld, we would have to leave the R_NONE relocations in, but I
think it's better to drop the relocations entirely. I'd hope that if
you're doing a -r link with gold, you'll also do the final link with
* ehframe.cc (Eh_frame::read_fde): Check for dropped functions.
* testsuite/Makefile.am (eh_test_2): New test.
* testsuite/Makefile.in: Regenerate.
* testsuite/eh_test_2.sh: New test script.
* testsuite/eh_test_a.cc (bar): Make it comdat.
* testsuite/eh_test_b.cc (bar): Add a duplicate copy.
Thank you, Cary!
Before I close this as fixed, I have a question: should gold also warn when it cannot build the .eh_frame_hdr section and --eh-frame-hdr is passed in? Would that be that useful?
The bfd linker warning about not being able to build .eh_frame_hdr was very useful for me.
Thanks for the fix.
I agree, I think the warning would be useful.