Crate findshlibs[−][src]

Expand description

`findshlibs`

Find the set of shared libraries currently loaded in this process with a cross platform API.

The API entry point is the TargetSharedLibrary type and its SharedLibrary::each trait method implementation.

Example

Here is an example program that prints out each shared library that is loaded in the process and the addresses where each of its segments are mapped into memory.

extern crate findshlibs;
use findshlibs::{Segment, SharedLibrary, TargetSharedLibrary};

fn main() {
    TargetSharedLibrary::each(|shlib| {
        println!("{}", shlib.name().to_string_lossy());

        for seg in shlib.segments() {
            println!("    {}: segment {}",
                     seg.actual_virtual_memory_address(shlib),
                     seg.name());
        }
    });
}

Supported OSes

These are the OSes that findshlibs currently supports:

Linux
macOS
Windows
Android
iOS

If a platform is not supported then a fallback implementation is used that does nothing. To see if your platform does something at runtime the TARGET_SUPPORTED constant can be used.

Is your OS missing here? Send us a pull request!

Shared libraries’ addresses can be confusing. They are loaded somewhere in physical memory, but we generally don’t care about physical memory addresses, because only the OS can see that address and in userspace we can only access memory through its virtual memory address. But even “virtual memory address” is ambiguous because it isn’t clear whether this is the address before or after the loader maps the shared library into memory and performs relocation.

To clarify between these different kinds of addresses, we borrow some terminology from LUL:

SVMA (“Stated Virtual Memory Address”): this is an address of a symbol (etc) as it is stated in the symbol table, or other metadata, of an object. Such values are typically small and start from zero or thereabouts, unless the object has been prelinked.

AVMA (“Actual Virtual Memory Address”): this is the address of a symbol (etc) in a running process, that is, once the associated object has been mapped into a process. Such values are typically much larger than SVMAs, since objects can get mapped arbitrarily far along the address space.

“Bias”: the difference between AVMA and SVMA for a given symbol (specifically, AVMA - SVMA). The bias is always an integral number of pages. Once we know the bias for a given object’s text section (for example), we can compute the AVMAs of all of its text symbols by adding the bias to their SVMAs.

Names and IDs

findshlibs also gives access to module names and IDs. Since this is also not consistent across operating systems the following general rules apply:

id refers to the ID of the object file itself. This is generally available on all platforms however it might still not be compiled into the binary in all case. For instance on Linux the gnu.build-id note needs to be compiled in (which Rust does automatically).

debug_id refers to the ID of the debug file. This only plays a role on Windows where the executable and the debug file (PDB) have a different ID.

name is the name of the executable. On most operating systems (and all systems implemented currently) this is not just the name but in fact the entire path to the executable.

debug_name is the name of the debug file if known. This is again the case on windows where this will be the path to the PDB file.