- 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.