This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lazy library loading


On 02/19/2013 05:16 AM, Andrew Senkevich wrote:
>> Glad to hear that! We are always interested in new developers helping
>> with the project.

Please void top-posting, the email etiquette for this list is to bottom-post.

> Very glad also!
> Please correct me if I am wrong, but at this moment my vision of problems is:
> 
> - To solve how analysis of inter-object data references will work. It
> must help to be sure that library is suitable for lazy loading.

Correct.

> - To define name of library containing needed symbol in the set of
> libraries in dependencies without their loading. We need to know which
> exactly object we must load.
> To solve it we propose to save this information statically in object’s
> ELF during building of library or executable. Runtime liker must use
> this information. Also required to have ability to mark some libraries
> for lazy loading and some not (during building).

I don't know if this is required or simply an optimization.

> - To have ability to load library just on first call from that
> library. Here we need to find out how current runtime linker resolves
> symbols in loaded libraries with lazy binding, and find a way of
> combining this existent functionality with addition of loading needed
> library just before it. (May be reuse dlopen() functionality for
> library loading in this case?)

Correct. Yes, we have the ability to load a library at any point in time.

> - In case of library containing constructor/destructor we need to have
> ability execute constructor after loading and addition of destructor
> to the destructor’s list. (But it works with dlopen(), so this
> functionality seems already implemented.)

Again that is correct, because of dlopen we have the ability to do this.

You will need to:

(a) Prevent the current dependency scanning system from loading any
    libraries.

(b) Enhance the resolver such that if the symbol requested is in a library
    that hasn't been loaded that the library should be loaded before trying
    to resolve the symbol.

(c) Provide performance measurements on how much the additional checks
    slow down the resolver.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]