This is the mail archive of the
mailing list for the binutils project.
Re: gold vs libc
- From: Ian Lance Taylor <iant at google dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Alan Modra <amodra at gmail dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 31 Mar 2014 13:53:44 -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>
On Mon, Mar 31, 2014 at 1:04 PM, Roland McGrath <email@example.com> wrote:
> When an input file contains a symbol pointing to a location in an
> input section, the output file should define that symbol so it points
> to the part of the output section that corresponds to the origin input
> location. When the symbol points to input contents of at least one
> byte, what this means is pretty incontrovertibly clear. In this case,
> it points to an empty input section. But I claim that it's adequately
> clear what it should mean in this case too.
It's really not. When the eh_frame section is being optimized, there
is no longer any correspondence between symbols defined in the input
sections and data defined in the output section. All the input data
is tossed in a heap, and the output section is constructed out of that
heap. I agree that when an input symbol points to some data in some
input section, and when we copy that input data unchanged, then the
symbol should clearly point to the same data in the output section.
That works fine for merge sections, for example. But that's not the
case here. There is nothing to locate the input symbol at any
location in the output section at all.
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