And then there are things like the layout of .gcc_except_table, which are undocumented except for random blog posts.
- assembly & ISA (instruction set architecture):
- Arm: https://github.com/MattPD/cpplinks/blob/master/assembly.arm....
- RISC-V: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...
- x86: https://github.com/MattPD/cpplinks/blob/master/assembly.x86....
- debugging: https://github.com/MattPD/cpplinks/blob/master/debugging.md
- debugging: tracing: https://github.com/MattPD/cpplinks/blob/master/debugging.tra...
- executable and object file formats (ELF, Mach-O, PE); debugging data formats (DWARF, PDB): https://github.com/MattPD/cpplinks/blob/master/executables.m...
- linking and loading: https://github.com/MattPD/cpplinks/blob/master/executables.l...
- compilers: https://github.com/MattPD/cpplinks/blob/master/compilers.md
- compilers correctness: https://github.com/MattPD/cpplinks/blob/master/compilers.cor...
Essentially they do as they put directives into the asm files to put things in specific sections, to define certain symbol visibility etc all of which depend on the object file format (e.g. a classic BSD a.out file, using a format I called “a.out” in BFD, can’t represent most of that). So the compiler does need to know. And the assembler absolutely needs to know since it generates object files!
So yes an a.out file can be an ELF file (always is on Linux) or could be an “a.out” file. Sorry! In retrospect I should have called that format “bsd”.
The way I dealt with it was write an ELF dumper for the tables, and then run various C++ code snippets through g++ and look at how the tables were constructed.
The same executable will also detect and dump Elf, Mach, MScoff, and OMF object files.
Besides, one doesn't learn anything about how to decode the format by using an existing tool that presents it in decoded form.