This is the mail archive of the
mailing list for the binutils project.
Re: gold vs libc
- From: Cary Coutant <ccoutant at google dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Ian Lance Taylor <iant at google 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: Thu, 11 Sep 2014 09:00:06 -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> <CAHACq4oRKDGKAUu3octDCxKg2EueCyf8kHWj0t8g9+LmE3JagQ at mail dot gmail dot com> <20140910225238 dot 0B6362C39CF at topped-with-meat dot com>
> In https://sourceware.org/ml/libc-alpha/2014-03/msg01012.html
> I said:
> 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.
As hard as that is to describe, it seems like it would be fragile.
> and also, in response to the cited suggestion from Ian:
> > The current code has a simple algorithm that usually produces the
> > result we want: we simply copy .eh_frame sections until we find one we
> > can optimize. Perhaps we could change to a different algorithm: put
> > all unoptimized .eh_frame sections first, then all optimized .eh_frame
> > sections.
> In the concrete scenario, that would violate the abstract principles I
> described but would deliver an even better practical result. The empty
> .eh_frame section (and its __EH_FRAME_BEGIN__ symbol) from crtbeginT.o
> count as "unoptimized", while the .eh_frame content from crt1.o could count
> as "optimized". So it would place the emptiness and __EH_FRAME_BEGIN__
> first, and everything else (including crt1.o's contributions) after, even
> though crt1.o appears before crtbeginT.o in the link.
> I think either this or disabling the optimization entirely are acceptable
> resolutions to the bug.
> I think that when Ian said, "we've identified a fix," he was referring to,
> "put all unoptimized .eh_frame sections first, then all optimized .eh_frame
That solution will end up putting the unoptimized end-bracket section
from crtend.o before the optimized contents. I've already fixed a bug
where --sort-section made that happen. Sure, that could be fixed, but
only by piling on another special case.
What we really want to do is put the optimized sections in between the
two bracketing sections. Identifying those bracketing sections is the
>> 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
> It doesn't need to and in fact it's undesireable that it do so. That is
> one reason in favor of Ian's suggestion: though it doesn't adhere to any
> clear abstract principle I can see, as a pragmatic solution to the actual
> case in point, it magically makes something even better in practice than
> the status quo ante (ante as in before switching linkers) long before a fix
> for the underlying wrongness (in GCC's link order) will be available.
> OTOH, it certainly seems like it has more risk of unintended consequences
> we aren't now able to predict than does simply disabling optimization.
So that's an argument against just turning off the optimization.
>> Since the problem comes from an optimizations that knows what
>> .eh_frame is, maybe it could learn that __EH_FRAME_BEGIN__ and
>> __EH_FRAME_END__ are special symbols marking the start and end of the
> I think that would be acceptable too. It would have the same benefits of
> "magically fixing" the crt1/crtbegin ordering snafu, but it seems much
> simpler and thus it seems that predicting possible downsides would be
> easier (I haven't thought of any).
I don't like the idea of checking for specific symbol name to give
special treatment to a section. I wouldn't mind simply making
__EH_FRAME_BEGIN__ and __EH_FRAME_END__ linker-defined symbols that
would override any definitions found in the object files.
I could also special case by filename -- check
is_in_system_directory(), and if true, check the filename to see if it
contains "begin" or "end".
I think I'd prefer to do the first. We have precedent for providing
linker-defined bracketing symbols -- not for having them override any
definitions already present, but I don't think that's a big problem in
this case. It's also simple, and lets us preserve the simple rule of
putting the linker-generated contents in the place of the first
BTW, my copy of crtend.o doesn't define __EH_FRAME_END__. It does
define __FRAME_END, but it's a local symbol. Having the linker provide
__EH_FRAME_END__ would be consistent, and shouldn't break anything.
With this proposal, __FRAME_END would get the right value anyway.
(Until, that is, someone comes along with another crtend-like file and
decides it needs CFI as well!)