Standardizing source maps(bloomberg.github.io) |
Standardizing source maps(bloomberg.github.io) |
https://github.com/EpicGamesExt/raddebugger?tab=readme-ov-fi...
First up is mapping from address to file, line and column. This one is basically a custom data compression scheme in the form a custom byte code. Strange but not too bad.
Second is “DWARF expressions", which is Turing complete and used for many things, such as figuring out where in memory or registers a given high level variable can br found at at any point of the program execution. It is baroque to say the least.
Then there is EH frames, which is used for unwinding (on exceptions in C++ or panics in Rust for example). This is used to specify how to find the base of the current stack frame given the current instruction pointer. This is needed if you don't use frame pointers. In itself it isn't Turing complete, but it can call out to Dwarf Expressions as subroutines, so it actually is TC. Except from what I have read, no compiler actually makes use of that capability, thankfully.
Surprisingly, the DWARF specification itself is actually reasonably readable and well written.
Stuff like this makes me believe open wins over closed in the end :)
This new standards process is making some useful improvements, though.
> figuring out where in memory or registers a given high level variable
Isn't the task itself Turing-hard? Or at least complex enough so that coming up with a non-Turing-complete solution would be impractical?
Basically, my impression was that that the format was flexible enough that I couldn't see why you would need the TC parts in practice. The compilers seemed to agree and not use it in practise (at least gcc and llvm).
This was of interest to me since I was generating BPF code from these (for user space trace points) and BPF is famously and intentionally not TC. I could translate many patterns that do show up in real world code, but not the general case.