[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: exporting symbols (was Re: The goodness of goodness)
From:       Michael Matz <matz () kde ! org>
Date:       2001-05-31 21:18:20
[Download RAW message or body]

Hi,

On Thu, 31 May 2001, Waldo Bastian wrote:
>
> Oh, that's not bad at all. Especially khtml is pretty impressive.

Yup.

> The 12591 of libkdeui is still high... can you check how many _different_
> symbols that involves?

I can:
The parentheses for R_386_PC are the number of unique symbols in that type
of reloc.  The other two relocs are already only unique symbols of course.

Without -Bsymbolic:
                          R_386_32        R_386_JUMP_SLOT   R_386_GLOB_DAT
libkdecore.so.3.0.0.old : 1708 (799)            1715            472
libkdeui.so.3.0.0.old   : 15660 (2523)          2870            1522
libkfile.so.3.0.0.old   : 3392 (884)            1008            479
libkhtml.so.3.0.0.old   : 13134 (2646)          2310            1132
libkio.so.3.0.0.old     : 1183 (514)            837             319
libkjava.so.1.0.0.old   : 321 (161)             227             63
libksycoca.so.3.0.0.old : 1017 (555)            789             277

And with -Bsymbolic:
libkdecore.so.3.0.0.new : 955 (210)             906             52
libkdeui.so.3.0.0.new   : 12591 (766)           1526            102
libkfile.so.3.0.0.new   : 2871 (485)            693             50
libkhtml.so.3.0.0.new   : 1414 (430)            874             73
libkio.so.3.0.0.new     : 689 (147)             458             23
libkjava.so.1.0.0.new   : 321 (161)             227             62
libksycoca.so.3.0.0.new : 522 (156)             456             29

Note how even with caching we could get rid of 15660-2523=13137 relocs
just in kdeui, without playing games with -Bsymbolic (which anyway doesn't
work as we want right now).

> The BSD linker guy improved link time quite a bit by caching the
> symbol lookups for R_386_32. I suggested to do that for ld-linux as
> well, but I don't think that was picked up (yet).

What also would be possible (although this violates ELF semantic) to play
games with the order symbols are searched in the different DSOs.  It would
be optimal if all symbols tables would be merged into one, which then is
searched (this can't be done easily in the current ld.so, because this
would need memory; anyway the merging would cost time).  Alternatively
(and this now violates ELF) ld.so could search the DSO first, in which the
last symbols was found or similar ordering tricks.  Unfortunately this
only works correct, when there are no symbol conflicts, which can't be
known in front.  Hmm.  Anyway there is light at the end of the tunnel:
did you get already Jakub's mail?


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]