Re: Shared libraries revisited

>>This implies poor dynamicity. I've found that replacing
>>system services with your own meta-service, which may, for
>>instance, count occurences, or something, is *extrememly* helpful
>>in debugging, especially so-called 'ring 3' services.
>
>I understand this, and agree. But now you indicate that you want
>to override the symbols called by the library at run time. If

Definately.

>you've already relocated the library, then presumably you've nailed
>down, say, fprintf()'s call to malloc() in the offered image.

Yes, in the shared image.

>How do you go back and change your mind when the user's program offers
>a new definition for malloc() (but inherits the libc fprintf())?

You don't go back. You don't run it with /magic/path in your 'search list'.
(If you feel this is a major problem, maybe some linker option
can specify this search path on a per-program basis.)

>Do you intend to keep the original, un-relocated library around
>as well, and spin off a new one as needed?

Yes. All you need is one file, the 'un-relocated' library, which
you prerelocate in memory at boot time. If a process wants to use
this shared image (i.e. has /magic/path in their LD_LIBRARY_PATH-type variable)
then it gets the post-relocated memory-resident version. If it doesn't,
then it gets the 'normal' one, non-relocated, and relocates normally,
based on LD_LIBRARY_PATH.

(To avoid any further confusion, I will point out that if you have
LD_LB_PATH=/foo/bar;/magic/path then you will load the image,
snap malloc being called from the executable to /foo/bar:malloc.
However, if the image calls /magic/path/libc:fprintf, which calls malloc,
this one will call the standard malloc, because everything in
/magic/path will have already been snapped. It's generally
considered not a great thing to do as production code, which is why I don't
think this is important. If you really *want* to replace a system
service, then create a standard shared library, make sure you pre-load
it before libc.a.)

This really isn't as complicated as it sounds, I'm probably over-explaining.
It's probably easier to write it than to explain the impact on all cases. :)
(No, I can't volenteer...:)

>Your claims concerning debugging are valid, but I think they could
>be covered by linking a static executable. This will give you the
>functionality. The extra memory/a.out size is probably irrelevant
>for a debugging version.

This assumes you have the source, not valid in any RL sense. (Consider
the case of error message "Can't Find Configuration File" from a (albeit
poorly written) application. Consider your delight when you trace the fopen
to find that it's looking for ~/.bagbiterc.)

> Andy

Thinking about it, I wonder if instead of search-lists of directories,
you might want to have a search-list of files, also:

LD_SEARCH_PATH=/foo/bar/bang.a;/magic/path/wubba.a;/magic/path;/foo/bar

Which would get bang.a first, then wubba.a, then everything in /magic/path,
then everything in /foo/bar. Just a thought....

--
Jason