On Sat, 2006-06-17 at 22:21 +0200, Mark Kettenis wrote: > > From: PAUL GILLIAM > > Date: Wed, 24 May 2006 16:26:11 -0700 > > > > --=-z0a1QHXPsj5sKoA5562L > > Content-Type: text/plain > > Content-Transfer-Encoding: 7bit > > > > On PowerPC-64, with 64-bit executables, GDB has been giving this message > > for a while: > > > > warning: Unable to find dynamic linker breakpoint function. > > GDB will be unable to debug shared library initializers > > and track explicitly loaded dynamic code. > > > > This is because "enable_break()" in solib-svr4.c was looking for the > > symbol "._dl_debug_state" in the 64-bit dynamic loader and not finding > > it. This should not be a surprise because these 'dot' symbols have not > > been used for a while. > > Your patch removes "._dl_debug_state" from the list of symbols. > Doesn't this break debugging old binaries that still have the 'dot' > symbols? No. The non-'dot' symbol "_dl_debug_state" will either be found in a code segment or in a data segment. If found in a code segment, we can set the breakpoint at where ever the symbol points. If it points to a function descriptor that's OK because if it's in the code segment, a function descriptor consists of executable code and a breakpoint can be set there. If found in the data segment, then it must be a function descriptor and it just gets "dereferenced". So I am attaching a new patch that addresses most of your comments in http://sourceware.org/ml/gdb-patches/2006-06/msg00382.html and deletes the "._dl_debug_state" entry in the table. One thing not addressed is this: > Also, I don't mind that the comment was rearranged, but I would like > to see information regarding the two linker symbols retained in some > fashion. The two linker symbols issue is no longer relevant for this piece of code: the "._dl_debug_state" symbol was just a crutch used to avoid having to "dereference" the function descriptor pointed to by "_dl_debug_state", should it happen to be in a data section. Now there is code to do just that. OK to commit?