LD_DEBUG=statistics and hp timing

[Jack Howarth]

In testing prelinking on ppclinux, I finally got Geoff's old
ppc-hp-timing patch working on glibc 2.2.94. However I am somewhat
puzzled by the details of its output. For example, if I create a
directory that is empty, cd into it and do...

LD_DEBUG=statistics ls

...I get...

03601:
03601: runtime linker statistics:
03601: total startup time in dynamic loader: 38935 clock cycles
03601: time needed for relocation: 17614 clock cycles (45.2%)
03601: number of relocations: 139
03601: number of relocations from cache: 5
03601: time needed to load objects: 17394 clock cycles (44.6%)
03601:
03601: runtime linker statistics:
03601: final number of relocations: 204
03601: final number of relocations from cache: 5

..where normally any listed files from the 'ls' command would appear
before the second runtime linker section. What puzzles me is why
the number of relocations differs from the final number of relocations.
I assume the first set of numbers reflect only relocations done in the
dynamic loader. Does the second set include relocations done elsewhere?
Thanks in advance for any clarifications.
Jack

[Jakub Jelinek]

Post by Jack Howarth
In testing prelinking on ppclinux, I finally got Geoff's old
ppc-hp-timing patch working on glibc 2.2.94. However I am somewhat
puzzled by the details of its output. For example, if I create a
directory that is empty, cd into it and do...
LD_DEBUG=statistics ls
...I get...
03601: total startup time in dynamic loader: 38935 clock cycles
03601: time needed for relocation: 17614 clock cycles (45.2%)
03601: number of relocations: 139
03601: number of relocations from cache: 5
03601: time needed to load objects: 17394 clock cycles (44.6%)
03601: final number of relocations: 204
03601: final number of relocations from cache: 5
..where normally any listed files from the 'ls' command would appear
before the second runtime linker section. What puzzles me is why
the number of relocations differs from the final number of relocations.
I assume the first set of numbers reflect only relocations done in the
dynamic loader. Does the second set include relocations done elsewhere?
Thanks in advance for any clarifications.

The first set is after the whole program and all libraries it depends on
are relocated during startup, the second numbers include
lazy binding relocations and relocations done because of dlopen too.

Jakub

[Jack Howarth]

Jakub,
Thanks for the explanation. That leads to a prelink question.
How exactly should one use prelink when dealing with programs
which load shared libs as modules via dlopen? I had assumed one
would definitely have to pass a --ld-library-path= to prelink
with the directory path to such modules. However it was unclear
to me if one needed to use -a as well to force any shared libs
(modules) in that dir to be prelinked or if presenting prelink
with the directory path via --ld-library-path was sufficient.
I guess one can always check this with LD_DEBUG=statistics by
making sure the final relocations are zero after prelinking
for anything that loads modules.
Jack
ps Would it be possible to get LD_DEBUG=statistics to output
references for exactly which binaries the stats are coming from?
For some programs like openoffice and mozilla it can become
difficult to sort out which set of statistics belong to which
binary being executed. It would be nice if there was an additional
field in the output simply referencing the binary name in question.

[Ulrich Drepper]

Post by Jack Howarth
How exactly should one use prelink when dealing with programs
which load shared libs as modules via dlopen?

Not at all. Prelinking and dlopen don't play together. There is no way
for prelink to find the dependency and record possible conflicts.

Post by Jack Howarth
ps Would it be possible to get LD_DEBUG=statistics to output
references for exactly which binaries the stats are coming from?

THe statistics are for the whole startup. So adding 'files' to the
LD_DEBUG list will show yuo among other things which files are involved.

- --
- ---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------

[Jack Howarth]

Ulrich,
It is interesting that you say that prelink and dlopen don't
play together. So far I have been able to prelink and run
mozilla, kedit and openoffice 1.0.1. The only failure I have
run into so far is evolution which starts up but then opens a
dialog reporting that a module failed to load. Is it possible
that prelink is incorrectly prelinking .so's in that evolution
opens by dlopen? I haven't debugged this yet on ppc and am
wondering if folks on i386 are able to prelink evolution 1.0.8
from rawhide and still have it run.
Jack

[Roland McGrath]

You should always be able to load a prelinked object even if the prelinking
can't be used--it should always fall back to doing full relocation. Please
try to figure out what exactly is going wrong, like what error from dlopen
it gets.

[Ulrich Drepper]

Post by Jack Howarth
It is interesting that you say that prelink and dlopen don't
play together. So far I have been able to prelink and run
mozilla, kedit and openoffice 1.0.1.

Don't play together only means you don't get the benefits of prelinking.
A dlopen()ed DSO is loaded just like before.

- --
- ---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------