On Mon Feb 26 06:48:52 2024 +0000, Rémi Bernon wrote:
The interface for JIT code is meant for block of code without any corresponding file on disk. It requires to load the debug info in memory, and attach it to the debugger notifications. It doesn't even support passing the module file name. This doesn't seem like a good fit to me, as we would need to find and load the debug info ourselves. On the other hand, using `_r_debug` would let us benefit from all the standard mechanisms. For instance, using `_r_debug` Gdb can find the debug link and load split debug info directly. Or even read the build-id, and lookup the PE file debug info in the systems debug info database.
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).