On Tue Mar 26 02:18:26 2024 +0000, Jinoh Kang wrote:
Quoting the GDB manual https://sourceware.org/gdb/current/onlinedocs/gdb.html/Registering-Code.html... [emphasis mine]
To register code with GDB, the JIT should follow this protocol:
Generate an object file **in memory** with symbols and other desired
debug information. The file must include the **virtual addresses** of the sections. This sounds twice as complicated as r_debug approach. Also, holding mostly-unused debug info will just waste memory.
I gave it a quick try, and I don't see what benefit it has over the r_debug approach.
The debugger still looks up a couple of predefined symbols which it hooks, these *have* to live in wine preloader, otherwise the debugger cannot find them, and it's pretty much the same kind of thing as `_dl_debug_state` for notifications and `r_debug` for the module map, but with different names.
Then, it doesn't save us the interactions between loader/wine and ntdll as the JIT map also needs to be populated, and that's pretty much something only ntdll can do, and ntdll needs to call the hooked function when it's done updating the map.
Also, last thing, I've tried with GDB and it looks like it expects the in-memory blobs to be object files, opens them with libbfd and also checks that it's compatible architecture with the debugged target. Both of these fail when passing the in-memory modules as-is, and we would need to generate ELF object blobs with the debug infos dynamically for every module. That seem more complicated than the `r_debug` approach which works OOTB.