Re: gold vs libc

[Ian Lance Taylor <iant@google.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.  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
sections.

Ian