This is the mail archive of the libc-alpha@sources.redhat.com 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]

Re: Prelinking of shared libraries


X-PMC-CI-e-mail-id: 15533 

>Yes, that seems the easiest way to do it. Some people pointed out a scheme 
>where you have a central "link/relocation service" (either in user or kernel 
>space) which maps the linked library into the address-space of the process. 
>Geoff Keating told me that AIX uses such an approach. That basically moves 
>the linking/relocation from installation time to "first used" time. I am not 
>exactly sure what the benefits of one of these schemes above the other has in 
>terms of use. Doing the linking/relocation at ldconfig time seems less 
>complex to me.

Long time ago, a minicomputer OS had such a service even for
figuring out to what an numerical address in an object file (or
an executable file) would resolve: "what" being a symbol and possibly
added offset.

>From the end user's point of view, 
this service simpilified certain tasks such as symbol priting
at the time of crash or writing one's own stack tracer, etc..
The service, I think, was offered since the 32 bit VM OS and
the old 16 bit OS were just merged and
there were two different types of the object files being
available.
Having the service in the kernel simplified the task of 
end users (mostly programmers) during the time when
the each successive revision of OS might introduce newer
object file types and relocation types and such, I think.

Of course, this is the pure end users's point of view.
>From the implementor's point of view, this just  moves
where the service is provided: in the kerenel via system call,
by system supplied libraries such as ELF handling libraries, etc..

The benefits to the end users would be the less dependence
on the object format changes and the required access
method changes as long as the user program
doesn't need the new features in the new object file format.


-- 
     Ishikawa, Chiaki        ishikawa@personal-media.co.jp.NoSpam  or         
 (family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
    Personal Media Corp.      ** Remove .NoSpam at the end before use **     
  Shinagawa, Tokyo, Japan 142-0051



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