On Mon Feb 26 20:38:39 2024 +0000, Jacek Caban wrote:
Do you know if GDB not putting a breakpoints on extended `_r_debug` is intended or a bug? It's not clear to me; I guess that if it's meant for a single loader with multiple namespaces then a single `r_brk` is enough, but the way those structures are arranged suggests that multiple break points make sense.
As far as I can see, it's not obviously a bug. It simply doesn't bother and only supports setting a breakpoint in the first `r_brk`. It even only does that when it can locate the main `_r_debug` from the `DT_DEBUG` entry statically, like I described above and which doesn't even work here. Otherwise a single breakpoint is set in one of the rendez-vous symbols instead, which might not even be the same as the main `r_brk`.
So, I think the options to make sure ld.so link map updates are seen are:
1) Redefine dlopen to hook it, and call the rendez-vous breakpoint before / after it has completed. We lose a bit of granularity as Gdb will only load the symbols after the constructors have been executed.
2) Hotpatch ld.so rendez-vous symbols to jump into ours. Hum?
3) Patch Gdb to hook every `r_brk` once it has located the first `_r_debug` (triggered the first time we call the rendez-vous breakpoint).
The last one is probably the cleanest but I'm still waiting for a feedback on my much simpler Python unwinder change, so... Well, I can always keep a fork like I do for Valgrind in the meantime.