Shared libraries: what functions are dynamically linked in?

[Rob Gingell]

In article <47793 at ut-emx.uucp> pefv700 at perv.pe.utexas.edu writes:
>Say you have a.out, a stripped executable that was linked dynamically with
>a shared library.  (nm won't work here, right?)  Assuming I did it right,
>ldd only told me, "Yes, it's using this shared library."  But I want to
>know the functions in the shared library that will be used when the
>executable is exec'd.

I've lost track of whether the original question referenced SunOS or
SVR4, but in either case the answer to the subject question is: "there's
no supported way to get a definitive answer."

At best, you can approximate it by looking to see what relocations remain in
the object to be examined.  For SunOS 4.x, you simply have to rummage around,
Sun supplies no tools other than adb and the #include files to help you with
this.  It's not for the faint of heart.

In SVR4, the "dump" command will give you the data -- "dump -rv <file>"
will show you the relocations being left to the dynamic loader, translated
to symbol names.  This will work whether or not the object in question
is stripped.  Previous suggestions to look at the namelist aren't really
going to cut it in all cases, and looking at the .dynsym symbol table
isn't always good enough either -- because there's no guarantee that there
is a section by that name -- simply a loose convention.

Still this won't show you how exactly they are resolved.  If there's only
one thing dynamically loaded, you can assume that it's the target for all of
them.  But if there are more, until the loader actually tries to resolve the
relocation you can only tell with a static inspection.  This isn't too hard,
but you just can't do it with a single command at present.

The dynamic loader in Sun's SVR4 can be coerced into dumping a very raw map of
the actual bindings -- it's a precursor to a real feature that would give
you a "load map" -- part of a general project to remove the various schisms
between the loaders and simply generalize the process with a single one.

But in the interim, you're left with "dump" or similar tools.

	- Rob Gingell