This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
remote debugging symbol problem
- From: David Antliff <dave dot antliff at paradise dot net dot nz>
- To: gdb at sources dot redhat dot com
- Date: Thu, 19 May 2005 12:26:33 +1200 (NZST)
- Subject: remote debugging symbol problem
Hello,
We use gdb-6.0 and a PowerPC port of gdbserver to remotely debug our
target application on it's PowerPC platform. Our application forks several
(20 or so) child processes shortly after starting up, and a few of these
child processes create threads.
Until quite recently, this has all worked fine. I was able to invoke:
# gdbserver 0.0.0.0:2345 --attach <pid> for any of the child processes,
and then run on my development host (x86 linux):
$ cd <application-src-dir>
$ gdb <application-binary>
I am 100% sure the same application binary is running on the host as on
the target (I'm using NFS).
Normally, once GDB is pointed at the target, the process is interrupted
and GDB can show a stack trace at the point of interruption.
However, now, I just get this:
(gdb) target remote 10.16.10.237:2345
Remote debugging using 10.16.10.237:2345
0x0fe896a0 in ?? ()
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
My understanding is that the warning is simply because the standard
libraries aren't compiled with GDB support. This used to happen even when
it worked so I'm not concerned about it (should I be?).
That address 0x0fe896a0 is always the same regardless of which child
process I attach to. There is no backtrace available (just prints out that
address and ?? again). I used the info commands to check the symbol table
is correct, and it is. Also:
(gdb) info target
Symbols from "<application-src-dir>".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
While running this, GDB does not access memory from...
Local exec file:
`<application-src-dir>/<application-binary>',
file type
elf32-powerpc.
Entry point: 0x10002aa8
0x10000114 - 0x10000121 is .interp
0x10000130 - 0x10000150 is .note.ABI-tag
0x10000150 - 0x1000081c is .hash
0x1000081c - 0x100016dc is .dynsym
0x100016dc - 0x10001ec9 is .dynstr
0x10001eca - 0x100020a2 is .gnu.version
0x100020a4 - 0x10002144 is .gnu.version_r
0x10002144 - 0x10002174 is .rela.sbss
0x10002174 - 0x10002a80 is .rela.plt
0x10002a80 - 0x10002aa8 is .init
0x10002aa8 - 0x1014ba9c is .text
0x1014ba9c - 0x1014babc is .fini
0x1014bac0 - 0x101be660 is .rodata
0x101ce660 - 0x102172bc is .data
0x102172bc - 0x102172c0 is .eh_frame
0x102172c0 - 0x102172d8 is .got2
0x102172d8 - 0x102172e0 is .ctors
0x102172e0 - 0x102172e8 is .dtors
0x102172e8 - 0x102172f8 is .got
0x102172f8 - 0x102173b8 is .dynamic
0x102173b8 - 0x10217dac is .sdata
0x10217db0 - 0x10218308 is .sbss
0x10218308 - 0x10218c5c is .plt
0x10218c60 - 0x104d4660 is .bss
'info sources' and 'info functions' show the expected output.
I've spent a few hours reading the GDB manual but I cannot find any clues
as to why this is happening. If I write a short main() loop and try
remotely debugging that, it works fine.
I have disabled all optimisations, and gcc is using -g3 (I've tried just
-g as well).
Does anyone have any ideas for further things I could try please? What
sort of things that can go wrong would cause this sort of problem or
these symptoms?
Kind regards,
David Antliff
NZ