With two[1] other[2] great articles about the guts of how programs _actually_ get loaded and run, I was reminded of the above great (multi-part) article, which I remember reading on the subway in tiny chunks and being surprised it ever works at all.

My CS degree was from a liberal arts university, and while I wouldn't trade anything for the coverage of ethics, previous AI bubbles/winters, and my time in the business and mathematics departments, these articles along with the glibc author's What Every Programmer Should Know About Memory[4] rounded out my education. I still make use of concepts from both when profiling and debugging programs.

[1]: https://news.ycombinator.com/item?id=45706938

[2]: https://news.ycombinator.com/item?id=45706380

[3]: https://www.cs.dartmouth.edu/sergey/cs108/ABI/UlrichDrepper-...

[4]: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

See also: https://stackoverflow.com/questions/8126311/how-much-of-what...

The ELF loading logic in the Linux kernel is intentionally very simple, so it's more like a bare-bones subset of what the dynamic linker handles. matheusmoreira summarizes it well in a previous discussion [0]:

> Yeah it turns out the kernel doesn't care about sections at all. It only ever cares about the PT_LOAD segments in the program header table, which is essentially a table of arguments for the mmap system call. Sections are just dynamic linker metadata and are never covered by PT_LOAD segments.

The simplicity of the ELF loader in Linux can be exploited to make extremely small executables [1], since most of the data in the ELF header is stuff that the kernel doesn't care about.

[0] https://news.ycombinator.com/item?id=45706380#45709203

[1] https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht...