On Tue Feb 27 18:49:27 2024 +0000, Rémi Bernon wrote:
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:
- 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 (it doesn't call it through its `r_brk` but statically). 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.
A 1b) option is to call the rendez-vous from ntdll, when it dlopen a library, this is also good enough for some use cases, though it'll miss dlopen called from elsewhere (but still could be enough if called soon after).
Also, this is only for automatic symbol loading, it's not 100% mandatory and it's always possible to manually load the symbols later from the shared library list entry.