gold vs libc

[Roland McGrath <roland@hack.frob.com>]

On the glibc.git branch roland/gold-vs-libc is the trivial configure change
necessary to let glibc attempt to build using gold as the linker.  (The
version check with that change is excessively loose--to boot, it admits
current gold versions so you can test, even though they don't work enough.)
i.e.:

	$ git clone git://sourceware.org/git/glibc.git
	$ git checkout roland/gold-vs-libc
	... make the ld in your path and found by the compiler be gold ...
	$ mkdir build
	$ cd build
	$ ../configure --enable-add-ons --prefix=/usr

The configure will fail the __ehdr_start check, which I've already posted
on the binutils list about.  This is not fatal.

	$ make -j...
	$ make -j... check

This will get test failures for nptl/tst-*-static (all but one of them).
(For me, there is one other FAIL, which is not a regression from libc built
by BFD ld.)  The affected tests are all statically-linked programs using
cancellation, i.e. unwinding.  I examined one in detail: tst-sem11-static.
I assume that the others are all suffering from the same gold bug.

I suspect the bug is in gold's .eh_frame optimization pass.  For me (with
trunk gold), the __EH_FRAME_BEGIN__ symbol (from gcc's crtbeginT.o--meant
to attach to the start of the .eh_frame output section) winds up pointing
at the end of .eh_frame rather than the beginning.  In the binary created
by BFD ld, the symbol points 48 bytes past the true start of .eh_frame,
which is exactly the size of crt1.o's .eh_frame contribution (so what we'd
expect given the input file order, albeit not what would be really right).

The .eh_frame in gold's output is a little smaller, perhaps suggesting that
it de-dup'd some CIEs and BFD ld didn't.  I'm not sure whether BFD ld does
.eh_frame optimization without --eh-frame-hdr (which isn't passed in this
static link).

Perhaps .eh_frame optimization just never really works with static linking
because there is no right answer for what a symbol like __EH_FRAME_BEGIN__
should stick to?  Hmm.  If the first CIE there happens to be one that's
de-dup'd then maybe it appears to make sense for the label to move to the
remaining other equivalent CIE, which might be way off into the section.

OTOH, crtbeginT.o is actually an input file that defines __EH_FRAME_BEGIN__
as a symbol in a zero-length .eh_frame input section.  So it seems more
unambiguous that this symbol should stick to that input file's relative
position in the output section, which I think is well-defined in theory
even when the input section is empty--rather than sticking to the
immediately adjacent content of another (file's) input section going into
the same output section, which if it's a de-dup'd CIE could be considered
to have "moved" to elsewhere in the output section.

At any rate, the symbol winding up exactly at the end of the .eh_frame
output section, as it does, seems clearly wrong.

gold hackers wanting to help gold finally get over the hump to being able
to build glibc could try the build from the branch and debug this issue.
glibc hackers wanting to help gold hackers achieve the same end could work
on reducing and isolating a test case that demonstrates the misbehavior
with the __EH_FRAME_BEGIN__ symbol without needing a whole pile of libc
build .o and .a files to make it happen.


Thanks,
Roland