This article is part 7 of the series Making our own executable packer:
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 now to get early access to all my posts. Learn more
