This is the mail archive of the
mailing list for the GDB project.
solist - internals: when ldd is in libc
- From: Aleksandar Ristovski <aristovski at qnx dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 15 Aug 2008 10:43:40 -0400
- Subject: solist - internals: when ldd is in libc
I have a question regarding the internals. We (qnx) have ldd in libc; qnx target is svr4, so we use solib-svr4; ldd is not listed in the process' link map. ldd lives in libc, but in .interp section it is called "ldqnx.so.2". Physically, ldqnx.so.2 is a softlink to real libc.so.2 (libc.so.3).
When GDB tries to determines current_sos before any shared object is loaded, it will call svr4_default_sos, which, in turn, will create "artificial" ldqnx entry in the gdb's so_list based on .interp name.
The problem: when the "real" libc is mapped, gdb will update_solib_list and determine that ldqnx is now missing from the inferior's linkmap and thus disable all the breakpoints set in it. I want to avoid disabling the breakpoints and let gdb "know" that newly mapped libc is, in fact, ldqnx mapped by default_sos; being one the same, all the resolved addresses for breakpoints are valid.
And this is, finally, my question: is there a mechanism in gdb to handle such situation, or would supporting this scenario be a new feature?
QNX Software Systems