On Thu Feb 29 21:58:43 2024 +0000, Jacek Caban wrote:
I don't see a reason why debugger wouldn't be able to load symbols, symbol links or build ids from the file when passed a PE file. My understanding is that the separated symbol blobs are meant to simplify things for JIT engines, so they can just generate a blobs without full ELF, but debugger could just fallback to its normal treatment when its got a proper image. For file module file names, the debugger could do the same thing as perf does and try to get it from the mapping. Moving the overhead of getting file names from Wine (where it's paid even when no debugger is involved) to the debugger does not seem like a bad thing. And even without that, it shouldn't be needed to get symbols, unless some relative links are involved. That said, I generally like the `_r_debug` idea. If we can make it work, that's fine with me. It's just preloader, loader, ntdll interaction that is not great. I don't have a good idea how to improve that part, the best I could think of is to try harder to not do it at all and handle PEs separately in ntdll. With JIT interface, the preloader part and debugger patch would still be needed to make gdb intercept ld.so (although perhaps we could then just set `DT_DEBUG` to ld.so `_r_debug` and use `_r_debug_state` to trigger gdb with your patch to hook it).
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.