pefv700@perv.pe.utexas.edu (04/22/91)
Since shared libraries have been discussed in this newsgroup... How can I find out what functions have been dynamically linked in an executable? Thanks.
urban@cbnewsl.att.com (john.urban) (04/23/91)
In article <47601@ut-emx.uucp> pefv700@perv.pe.utexas.edu writes: > >Since shared libraries have been discussed in this newsgroup... > >How can I find out what functions have been dynamically linked in an >executable? > >Thanks. You can see what functions whould be linked in by typing in: mn /usr/lib/libc.so.1 To see which executables are using dynamic shared libraries, type in: mcs -p -n .interp full_path_name At least this is how it works on: AT&T UNIX System V/386 Release 4.0 Sincerely, John Urban
guy@auspex.auspex.com (Guy Harris) (04/24/91)
>You can see what functions whould be linked in by typing in: > mn /usr/lib/libc.so.1 (Assuming you meant "nm", not "mn"), that'll show all the functions that are in the shared library, regardless of whether any particular executable uses them or not. I'm not sure which the original poster wanted. >To see which executables are using dynamic shared libraries, type in: > mcs -p -n .interp full_path_name > >At least this is how it works on: AT&T UNIX System V/386 Release 4.0 Somewhat the same in SunOS 4.x (not surprisingly...), except that there ain't no "mcs" command or ".interp" section, so you just use "file" to see if an executable is using dynamic shared libraries. "ldd" should work in S5R4 (the stuff shown for S5/386R4.0 should apply to any S5R4 implementation) and in SunOS 4.x.
pefv700@perv.pe.utexas.edu (04/24/91)
In article <7355@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes... >>You can see what functions whould be linked in by typing in: >> mn /usr/lib/libc.so.1 > >(Assuming you meant "nm", not "mn"), that'll show all the functions that >are in the shared library, regardless of whether any particular >executable uses them or not. I'm not sure which the original poster >wanted. Well, since I'm the original poster, I'll try to clarify. 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.
urban@cbnewsl.att.com (john.urban) (04/25/91)
In article <47793@ut-emx.uucp> pefv700@perv.pe.utexas.edu writes: >Well, since I'm the original poster, I'll try to clarify. > >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. If you don't have the source for a.out and it's stripped it is really hard to figure this out. $ ldd a.out This will tell you if it uses dynamic shared libraries or not. Unless you wrote your own version of a particular function it will use the one from the dynamic shared library (if there is one there). $ nm /usr/lib/libc.so.1 | grep "|FUNC |" | cut -f8 -d'|' | sort | uniq | > pr -5 | pg This will give a sorted list of all the functions available in the dynamic shared library. $ what a.out -OR- mcs -p a.out This will give a dump of the comment section of the a.out. strip doesn't clear this. mcs -d will. Often this gives you the name of the functions. Sincerely, John Urban
scottl@convergent.com (Scott Lurndal) (04/26/91)
In article <47793@ut-emx.uucp>, pefv700@perv.pe.utexas.edu writes: |> In article <7355@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) 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. For non-stripped executables: nm a.out | grep UNDEF for stripped executables: dump -v -s -n .dynsym a.out | grep UNDEF (This works on SVR4.0 systems) scott
gingell@opus.Eng.Sun.COM (Rob Gingell) (04/28/91)
In article <47793@ut-emx.uucp> pefv700@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