On Mon, Nov 21, 2022 at 9:14 AM Nick Clifton <nickc@redhat.com> wrote:

> Hi Tom,
>
> > Isee the following output from readelf for the lld, gold and bfd linkers
> > (binutils 2.39, lld 14.0.6)
>
> To be clear - this is not a readelf problem.  It is showing you the correct
> results.  It is the fact that the three linkers are not producing identical
> output and instead showing slight variations in their layout of the linked
> binary that is bothering you, yes ?
>

It's not bothering me so much as I was wondering if this would point to an
issue with slow start up times.  Reading your reply in totality, I now see
this
should not make a difference.


> In general variations in the layout like this should not make any
> difference
> to the program#s startup time.  There might - possibly - be variations in
> performance due to affects like cache misses and the like, but this is hard
> to quantify in isolation.
>

I didn't stop to think about caching and the like for relocations at start
up.  I was
testing with the perf tool and LD_DEBUG=statistics to see how much time was
spent in start up by symbols/relocations.  Results varied from run to run,
so I can
now see how caching may play into this.

> Output below.  Notice how the ordering is different in each case.  The
> > interesting thing about this is, and why I am looking at various
> > differences between object code linked by these three linkers, is that I
> am
> > trying to track down why startup times are slower due to relocations
> (based
> > on the perf tool output).  Would any of these differences make, well, a
> > difference in startup time?
>
> I don't think so.  The number of relocations is the same, so the amount
> of start up time spent resolving them should effectively be the same as
> well.
>
> I assume that you have compared started up times when linking with "-z now"
> vs "-z lazy" ?
>

I thought -z lazy was the default, and that if you wanted the equivalent of
LD_BIND_NOW=1
on the command line, then one would use -z now.  We don't want the latter,
we already spawn
enough processes that -z now would slow things down even more.  I can try
with -z lazy and
report back.

Thanks for the input,

Tom