On Linux you can inspect /proc/$PID/pmaps to see the libraries loaded by a particular program, and a program can open /proc/self/pmaps to examine the libraries it itself has loaded.
I know pmaps will only contain dynamic libraries, and obviously the kernel can’t predict which libraries we might dlopen at a later point, so I expect those aren’t included in /proc/self/maps. But I’m unsure of a few other other scenarios:
-
Are libraries that have been linked at build time but we haven’t called any function in yet included? My understanding is the Linux delays linking symbols until the first time they are used, so I’m not sure if they’ll show up.
-
Does pmaps contain all the libraries used recursively? E.g. if I look at each library in pmaps and run ldd on it, and then run ldd on those, ad nauseum, I shouldn’t find any new libraries that weren’t in the original pmaps? I tried this on a couple binaries and it appears to be so but maybe I’m getting lucky.
Yes: the runtime loader will
mmapevery library that your executable directly depends on, before your program starts running.You can find the list of such libraries by running
Yes: if a library that you directly depend on itself depends on some other library, the runtime loader will
mmapthe recursive dependencies as well.That is mosty correct for function symbols, but false for data symbols, which can’t be resolved lazily.
Also, whether the symbols are resolved lazily or not depends on
LD_BIND_NOWenvironment variable, and on an equivalent setting in the executable dynamic section, controlled by-znowlinker flag.None of that changes the
mmappciture though; if you have aDT_NEEDEDentry forfoo.soin your dynamic section, thenfoo.sowill bemmaped (and will show in/proc/self/*map*) independent of lazy or non-lazy resolution.