RE: multithreaded remote debugging

["Frank van Eijkelenburg" <frank dot van dot eijkelenburg at technolution dot nl>]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: vrijdag 17 januari 2003 15:56
> To: Frank van Eijkelenburg
> Cc: Gnu Debugger mailing list
> Subject: Re: multithreaded remote debugging
>
>
> On Fri, Jan 17, 2003 at 03:51:48PM +0100, Frank van Eijkelenburg wrote:
> > > > > > Hi, I'm new to gdb. I try to remote debug an application:
> > > > > >
> > > > > > I have a linux machine with redhat installed (2.4.7-10), this
> > > > > is the host.
> > > > > > On the target an ARM processor is running with linux kernel
> > > 2.4.16. I
> > > > > > compiled gdb on the host (with target arm-linux). I also
> > > cross-compiled
> > > > > > gdbserver. My application (which I want to debug) is compiled
> > > > > with compiler
> > > > > > option -g. I can start the gdbserver on the target and gdb on
> > > > > the host and
> > > > > > have a connection by tcp/ip. The application is multithreaded
> > > > > and uses the
> > > > > > libpthread library. If I ignore the SIG32 signal (with "handle
> > > > > SIG32 nostop"
> > > > > > and "handle SIG32 noprint") I can run the application. However,
> > > > > if I try to
> > > > > > execute "info threads" I only get information about one
> > > thread (the main
> > > > > > thread??). I can put breakpoints in the main thread and
> > > step through the
> > > > > > code, but if I put a breakpoint in another thread, the debugger
> > > > > will stop,
> > > > > > but I cannot step through the code:
> > > > > >
> > > > > > Program received signal SIGTRAP, Trace/breakpoint trap.
> > > > > > 0x400ab2e4 in ?? ()
> > > > > > (gdb) n
> > > > > > Cannot find bounds of current function
> > > > > >
> > > > > > What do I wrong or is it not possible to step through the
> > > code of other
> > > > > > threads beside the main thread?
> > > > >
> > > > > You neglected to say what version you're using.  We only
> got support
> > > > > for remote thread debugging between GDB 5.2 and 5.3; if you aren't
> > > > > using 5.3, you should try it.
> > > > >
> > > >
> > > > Sorry about that. I am using GDB version 5.3 with the above
> described
> > > > problems.
> > >
> > > Do you have libthread_db installed on your target, and on your cross
> > > development system so that gdbserver can link to it?  Look at the
> > > output of "configure" in the gdbserver directory, or at config.log.
> > >
> >
> > I think the problem is in the libraries. I tried some simple
> sample code and
> > debugged this on the host machine (it was linking /lib/libpthread.so.0).
> > This worked like I expected (I could see multiple threads with the "info
> > threads" command).
> > Gdbserver is crosscompiled with the libthread_db.so.1, which is also
> > installed at the target. But the application is linked against a
> > libpthread.a.
>
> In order to do remote thread debugging, you need:
>   - libthread_db.so.1 on the target
>   - a copy of the application and any dynamically linked libraries on
>     the host where GDB can access them
>
> The copy on the host must not be stripped, because it must contain
> certain symbols which libthread_db.so.1 looks up.
>
> If those are both the case, could you post a session log; use "set
> debug remote 1" before connecting and run until a SIG32.

libthread_db.so.1 is installed on the target. I have a copy of the
application on the host. Actually its the same file as the target uses. I
mount the directory with the application from the host at the target. Do I
have to tell gdb where to find some directories?

The application is not stripped. And here is a session log:

(gdb) handle SIG32
Signal        Stop      Print   Pass to program Description
SIG32         Yes       Yes     Yes             Real-time event 32
(gdb) set debug remote 1
(gdb) target remote 172.16.200.100:2345
Remote debugging using 172.16.200.100:2345
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: T050b:00000000;0d:10feffbf;0f:10250040;
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received:
00000000e6feffbf000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000010feffbf0000000010250040000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000010000000
Sending packet: $m40002510,4#59...Ack
Packet received: 0d00a0e1
Sending packet: $m40002510,4#59...Ack
Packet received: 0d00a0e1
Sending packet: $m0,4#fd...Ack
Packet received: ffffffff
0x40002510 in ?? ()
Sending packet: $m2085340,a8#98...Ack
Packet received:
01000000fc0300000f000000f20c00000c000000dc2c00020d000000e4a50602040000003001
0002050000001018000206000000400800020a000000070d00000b0000001000000015000000
0000000003000000cc4f080202000000600300001400000011000000170000007c2900021100
00007427000212000000080200001300000008000000feffff6f34270002ffffff6f01000000
f0ffff6f382500020000000000000000
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:5f5f707468726561645f746872656164735f6576656e7473
Packet qSymbol (symbol-lookup) is supported
Sending packet:
$qSymbol::5f5f707468726561645f746872656164735f6576656e7473#47...Ack
Packet received: OK
(gdb) c
Continuing.
Sending packet: $Z0,4000e630,4#d8...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m4000e630,4#8f...Ack
Packet received: 29e04be2
Sending packet: $X4000e630,0:#b0...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M4000e630,4:01009fef#d4...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T4d0b:3cfbffbf;0d:1cfbffbf;0f:34050440;

Program received signal SIG32, Real-time event 32.
Sending packet: $g#67...Ack
Packet received:
fcffffff080000000000a0bf04ee07021cee070240fbffbf020000005037104060e20a02ac4f
0a024ce10f403cfbffbf1cfbffbf1cfbffbf2405044034050440000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000010000020
Sending packet: $m40040534,4#61...Ack
Packet received: 0040a0e1
Sending packet: $m40040534,4#61...Ack
Packet received: 0040a0e1
Sending packet: $mbffffb3c,4#bf...Ack
Packet received: 04050440
Sending packet: $m400404fc,4#c2...Ack
Packet received: b0a09fe5
Sending packet: $m40040500,4#5a...Ack
Packet received: b0209fe5
Sending packet: $m40040504,4#5e...Ack
Packet received: 0aa08fe0
Sending packet: $m40040508,4#62...Ack
Packet received: 02709ae7
Sending packet: $m4004050c,4#8d...Ack
Packet received: 04b04ce2
Sending packet: $m40040510,4#5b...Ack
Packet received: 003097e5
Sending packet: $m40040514,4#5f...Ack
Packet received: 0050a0e1
Sending packet: $m40040518,4#63...Ack
Packet received: 000053e3
Sending packet: $m4004051c,4#8e...Ack
Packet received: 1700001a
Sending packet: $M4000e630,4:29e04be2#d6...Ack
Packet received: OK
0x40040534 in ?? ()
(gdb)