rewritten about 6 times, as each code scenario played out, had
a crink - me taking a shortcut.
The most recent prior release had issues because I had fudged
a "hole" into the ELF binary and although the file was well formed,
libbfd didnt like this (eg "strip" gave all sorts of diagnostics and
wrote out an invalid ELF file as a result).
The final algorithm is simple: add the .hash table just prior to the
start of the LOAD/phdr code segment. Rather than appending, we are prepending.
We have a nice free chunk of address space to achieve this, and
the first attempt was blighted by smashing in the data without honoring
the contract that the PHDR should following the EHDR.
Here is what an ELF file should look like:
+----------------------------+
| Elf Ehdr |
|----------------------------|
| PHDR (Program Hdr) |
|----------------------------|
| section #1 data (.text) |<---
| | |
| | |
|----------------------------| |
| section #2 data (.data) | |
| |<--------
| | | |
|----------------------------| | |
| .... | | |
| | | |
| | | |
| | | |
|----------------------------| | |
| Section table | | |
| | #1 | addr | size | |---- |
| | #2 | addr | size | |--------
| | ... | | | |
+----------------------------+
The program header is important because it is used by the kernel
to load the needed segments into memory (via mmap() type technology)
and most apps will require two memory map ranges - one for the .text/code
and another for initialised data. A real executable typically
contains 30 or more sections, breaking down the app into code,
read-only data, bss data, and various housekeeping segments for things
like debugging, and relocations.
The format itself is elegant and simple, and extensible. The
libelf libraries provide object-oriented like access to such
files, for reading or creating, but the library can be opaque
and difficult to use when things go wrong.
Post created by CRiSP v10.0.2c-b5920
No comments:
Post a Comment