Re: transpiling to low level C

On 12/22/2024 8:08 PM, Lawrence D'Oliveiro wrote:

On Wed, 18 Dec 2024 23:46:21 -0600, BGB wrote:
 

... (what debug mechanisms I have, effectively lack any symbols
for things inside "ld-linux.so"'s domain).

      nm -D /lib/ld-linux.so.2

It is not actually on Linux, but rather trying to make my kernel mimic Linux...
The issue isn't getting the symbol map, but rather that in this case, there are multiple levels of abstraction and so, at the level of the CPU emulator (where I can get instruction traces when something crashes), it can no longer figure out what addresses map to where.
With the normal PE loader, it can send messages to the virtual debug UART which signal where it has loaded things in memory (for every EXE and DLL). But, things partly break down for ELF PIE binaries with glibc or musl.
Granted, the ELF loader does at least know in theory where the main binary and interpreter were loaded.
But, seemingly, process is sort of like:
   Read in main ELF binary;
   Read in interpreter;
   Set up argument list, environment, and other stuff (*1), on the stack;
   Branch to entry point on interpreter;
   Magic happens.
     (Currently, it just crashes).
*1:
   (SP+ 0): argc
   (SP+ 8): argv[0]
   (SP+16): argv[1]
   ...
   (SP+(argc+1)*8): NULL
   (SP+xx): Env var pointers...
   (SP+xx): NULL
   (SP+xx): Auxiliary Vectors
     Key/value pairs
     Terminated by Key==0
Information on how exactly to set up the auxiliary vectors in a way that glibc and musl are happy, is harder to figure out. At this stage, things become rather poorly documented.
Theoretically the interpreter program is responsible for loading the other SO's; or if the main ELF loader is supposed to do it, it is not obvious how it is supposed to tell ld-so where it had loaded them.
...