Re: On the cost of libraries

[Alex Larsson <alexl redhat com>]

On Sat, 1 Sep 2001, Drazen Kacar wrote:

> Alex Larsson wrote:
> 
> You need to make a difference between function and data symbols, since
> they are handled in a different way. Data relocations must be processed
> before the application gains control. Lookup for function symbols can be
> deferred. Having data relocations is bad for a number of reasons.

Yeah. This was only function symbols. 
 
> > [...] and lower level libraries are (hopefully) linked earlier.
> 
> Like libc? No, they are usually linked in later.

Oops.
 
> The penalty depends on what your linker can do. No-penalty case is
> something like this:
> 
>   a) outlaw run-time symbol interposition in the dependencies which were
>      not marked as interposers.

What is a "run-time symbol interposition", and how would i mark it as an 
interposer? (And what is an interposer?)
 
>   b) then ld(1) can record in which library every simbol lives.

Do i have to tell ld to do this?
 
>   c) run-time linker doesn't have to search libraries in the mapping order,
>      because the right library is known. (Unless there were interposers,
>      but this is a fairly rare condition. Even in that case, extra
>      lookup time is limitted by the number of interposers, not by the
>      number of dependencies.)
> 
>   d) while we're at it, the libraries which probably won't be used can
>      be marked for lazy loading (or deferred loading, or however your
>      system documentation calls it). If those libraries have good enough
>      API, run-time linker won't load them until needed.

Is this possible with Linux + GNU ld? I've never seen anything about it.
 
> I would strongly recommend against libraries having data which is not
> accessed by functional interfaces. If there is such data, the library
> must be loaded even if it will never will be used and run-time linker
> must process data relocations.
> 
> And all private symbols in the libraries should be marked as such.

Yes. Maybe we should sweep through all our libraries and see if we can fix 
this for Gnome 2?

/ Alex



_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers