This is the fourth article in a multi-article series on Linux program loading. I originally thought it would be a three-article series, but it now seems like I may have enough material for many more. To keep things nice and ambiguous, I will call it a 'multi-part' article.

The first article was primarily background information. The second article talked about statically-linked executables, and how to load them. The third article talked about the startup environment that a program is given. Now it's time to start talking about the dynamically-linked executables. Sadly, I don't think we'll get very far in this article.


TODO: what is dynamic linking?

TODO: why dynamic linking? (exec size, memory use, etc.)

TODO: use ldd to illustrate

TODO: ELF symbols

As I've insinuated before, the topic of dynamic linking is a huge one. So, how to begin the gargantuan task of describing it? Well, we'll start with something kind of central: the .dynamic ELF section.

The .dynamic section

Remember how an ELF file is separated into different regions, called sections? Any dynamically-linked ELF executable will have a section called .dynamic; this section stores all of the high-level information about how this file should be dynamically linked. That is to say, it doesn't provide the list of symbols that are needed, but it does provide the names of the libraries where those functions can (probably) be found.

Investigating disassemblies

Okay, so that's some high-level information about dynamic linking.

TODO: briefly talk about PLT, GOT, using implementations as reference


- ethereal