Dynamic symbol resolution
Feb 2, 2020
36 minute read

Let's pick up where we left off: we had just taught elk to load not only an executable, but also its dependencies, and then their dependencies as well.

We discovered that ld-linux walked the dependency graph breadth-first, and so we did that too. Of course, it's a little bit overkill since we only have one dependency, but, nevertheless, elk happily loads our executable and its one dependency:

$ ./target/debug/elk ./samples/hello-dl
Loading "/home/amos/ftl/elk/samples/hello-dl"
Found RPATH entry "/home/amos/ftl/elk/samples"
Loading "/home/amos/ftl/elk/samples/libmsg.so"
Process {
    search_path: [
        "/usr/lib",
        "/home/amos/ftl/elk/samples",
    ],
    objects: [
        Object {
            path: "/home/amos/ftl/elk/samples/hello-dl",
            base: 00400000,
        },
        Object {
            path: "/home/amos/ftl/elk/samples/libmsg.so",
            base: 00400000,
        },
    ],
    objects_by_path: {
        "/home/amos/ftl/elk/samples/hello-dl": 0,
        "/home/amos/ftl/elk/samples/libmsg.so": 1,
    },
}

Something doesn't look quite right though - right now they have the same base address. Of course, this is a half-lie: we haven't mapped either of these into memory yet, so it's not like there's a conflict yet. But we're definitely going to have to pick different memory addresses.

Want to read more?

This post is Patreon-exclusive until February 23, 2020

Become a Patron! 2020-02-23T07:30:00.000Z 2020-02-23T07:30:00.000Z UTC 📖 Dynamic symbol resolution Now available: https://fasterthanli.me/blog/2020/dynamic-symbol-resolution/ Log in

Become a Patron now to get early access to all my posts. Learn more