This is the mail archive of the
mailing list for the glibc project.
Re: gold vs libc
- From: Cary Coutant <ccoutant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Alan Modra <amodra at gmail dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>, Rafael Ãvila de EspÃndola <rafael dot espindola at gmail dot com>
- Date: Wed, 10 Sep 2014 13:56:51 -0700
- Subject: Re: gold vs libc
- Authentication-results: sourceware.org; auth=none
- References: <20140330042516 dot 1A88E74481 at topped-with-meat dot com> <20140330045552 dot GX18201 at bubble dot grove dot modra dot org> <20140330050615 dot 7DC5774481 at topped-with-meat dot com> <CAKOQZ8wPgdHfA9QJWQ9yVO9gVQKL=HF-rpuipCBxzsx3=TcqwA at mail dot gmail dot com> <20140331200446 dot A09B074430 at topped-with-meat dot com> <CAKOQZ8x19YZ_oyJXyxe9JST4nfaG8dDvVrdf-vmgkNWydrpsrw at mail dot gmail dot com> <20140331214025 dot E61517447E at topped-with-meat dot com> <CAKOQZ8x1W0YxJSq+X74EjMj7_02uTZq82qzhmF=oQ-cTd4S1mQ at mail dot gmail dot com>
Adding Rafael, since he ran into this issue again...
>> IMHO it would be acceptable to simply disable .eh_frame optimization when
>> there are any symbols in input .eh_frame sections that will survive to
>> affect the output of anything except the .eh_frame output section's
>> contents. (That tortured wording is to distinguish __EH_FRAME_BEGIN__,
>> whose value is used by relocs in other sections like .text, from the
>> various .L* symbols used within individual input sections that are only
>> used in arithmetic producing values inside the section.) What's not
>> acceptable is breaking the core semantics of linking that would apply if
>> nobody had ever thought of .eh_frame optimization.
> I would say that the handling of a symbol attached to no data is not
> part of the core semantics of linking.
I wouldn't go that far -- it's a common-enough trick that I think it
really is one of the core features. Preserving link order is important
enough that we only violate that principle when explicitly told to do
so (e.g., merge strings or constants, optimize sections, etc.). And in
the case of optimized .eh_frame data, we actually do go to some
trouble to preserve the key expectations.
> I freely grant that GCC's crtbegin.o file tries this trick in a number
> of different ways--even worse, crtend.o has trailing symbols. Because
> of this existing behaviour, gold has various special cases to make it
> continue to work. One of those special cases is for
> __EH_FRAME_BEGIN__. As you've seen, the existing special case does
> not work any more. This is an unfortunate interaction. I don't think
> it's an obvious bug.
The problem isn't so much the bracketing symbols in crtbegin.o and
crtend.o. When gold optimizes the .eh_frame section, it tries to
preserve the order by placing the optimized contents where the first
optimizable input section appeared in the link order. Assuming that
the starting symbol actually precedes the first optimizable input
section, this produces the results you'd expect, and the optimized
data will appear between the two bracketing symbols.
When there's an optimizable input section that appears before the
bracketing symbol, it's not clear to me why the linker should be
expected to figure out what is really meant. Should we put the
optimized data in place of the second non-empty, optimizable, input
section? The third? The last?
> In any case I think we've identified the problem and we've identified
> a fix. Someone just needs to implement it.
Have we identified a fix? From my point of view, the proper fix is to
reorder the crt files so that the __EH_FRAME_BEGIN__ symbol *precedes*
any non-empty .eh_frame sections. Why is this not possible? Don't we
all agree that it's silly to have the start symbol follow some actual
If you want to disable .eh_frame optimization in this case, what are
the specific conditions under which we should not do it? When
--eh-frame-hdr is not specified? When we're doing static linking? When
we see a zero-length section with a symbol that comes after a
non-zero-length section, but isn't an end bracket? (How should we tell
the start bracket apart from the end bracket?) When we see a non-zero
length section in a file named "crt1.o"? None of these strikes me as
particularly elegant (or future-proof).
If the .eh_frame data in crt1.o really does need to come before
__EH_FRAME_BEGIN__, another thing you could do is simply make it so
gold treats it as non-optimizable. Adding a null relocation to the
first word of the section should do it; inserting a zero-length entry
anywhere but the end would do it (if that doesn't have adverse affects