Re: gold vs libc

[Ian Lance Taylor <iant at google dot com>]

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

The user is trying to do something special, and the linker is trying
to do something special, and the two are colliding.  The user is
defining a symbol in one file and assuming that it will name data
defined in a different file.  The linker is applying special treatment
to a particular section type.  The two uses collide.  This collision
can happen in a number of different ways.  For example, the same kind
of thing will happen for a symbol attached to no data in a SHF_MERGE
section.  Or a .note.GNU-stack section.  Or a .gnu.attributes section.
And sections can be eliminated due to ICF.  And incremental linking
can change section ordering.  So can GC and ICF.

You are assuming that the linker is simpler than it is.  In the
absence of a linker script, the linker will reshuffle sections and
symbols as it sees fit.  It makes certain obvious guarantees.  For
symbols attached to no data, the kind of handling you expect is not
one of them.


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


In any case I think we've identified the problem and we've identified
a fix.  Someone just needs to implement it.

Ian