Re: gold vs libc

[Roland McGrath <roland at hack dot frob dot com>]

> On Mon, Mar 31, 2014 at 1:04 PM, Roland McGrath <roland@hack.frob.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.

I understand that's what's going on underneath.  But the user didn't ask
you to fiddle with his .eh_frame contents.  He did ask you to place some
symbols in his .eh_frame section.  If .eh_frame optimization is not
transparent, then it's broken.

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.

> 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.


Thanks,
Roland