
The missing link: explaining ELF static linking, semantically (2016) [pdf] - signa11
https://www.researchgate.net/publication/311466566_The_missing_link_explaining_ELF_static_linking_semantically
======
nineteen999
Despite all the complexity that goes into _creating_ a statically linked ELF
executable as the PDF describes, I was reminded exactly how easy it is to
unwrap and load a static ELF binary into memory when I was writing a static
ELF loader the other week.

You literally end up with a table ("section header table") in your executable
with sections of type "SHT_PROGBITS" and "SHT_NOBITS". You copy <n> bytes from
the offset in the ELF image for the former to the address specified, and zero
<n> bytes at the address specified for the latter.

Obviously in a system with virtual memory, you need to account for page table
mappings, and for a multiprocessing system you need to setup a process vector
with initial instruction pointer, address of the page tables etc. so that you
can task switch.

But for the most basic case (ie. a DOS or CP/M workalike) you can pretty much
wallop the program into memory and jump or call to the entry point.

~~~
nils-m-holm
Even creating ELF executables is not particularly hard. As the article says,
the complexity is in the linker. If you keep track of depedencies yourself,
creating an ELF binary boils down to writing a header and aligning the text
and data segments properly.

Here is a _full_ compiler that emits ELF in about 1600 lines of code (the ELF
emitter is about 50 lines in size, most which deals with generating the
header):

[https://www.t3x.org/t3x/t.t.html](https://www.t3x.org/t3x/t.t.html)

~~~
nineteen999
That is a fascinating project, thanks for sharing.

------
signa11
this
([https://www.youtube.com/watch?v=dOfucXtyEsU](https://www.youtube.com/watch?v=dOfucXtyEsU))
is also pretty good.

