multithreaded remote debugging

multithreaded remote debugging

[Frank van Eijkelenburg]

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?
TIA

      Frank van Eijkelenburg
      System Designer

--------------------------------------------------------------------------

      Technolution B.V.
      Telephone:  +31(0)182 59 40 00
      Fax:  +31(0)182 53 97 36
      E-mail:
     frank.van.eijkelenburg@technolution.nl

      Visit us at:
     www.technolution.nl

      Mailing address:
     P.O. Box 2013 - 2800 BD Gouda - The Netherlands

      Address:
     Zuidelijk Halfrond 1 - 2801 DD Gouda - The Netherlands

      GPS:
     N 52º.00'58,2” O 4º.41'05,2”


--------------------------------------------------------------------------
      This e-mail is intended exclusively for the addressee(s), and may not
be passed on to, or made  available for use by any person other than the
addressee(s).  Technolution B.V. rules out any and every liability resulting
from any electronic transmission.

Re: multithreaded remote debugging

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 12:29:16PM +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.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: multithreaded remote debugging

[Frank van Eijkelenburg]

> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel Jacobowitz
> Sent: vrijdag 17 januari 2003 14:54
> To: Frank van Eijkelenburg
> Cc: Gnu Debugger mailing list
> Subject: Re: multithreaded remote debugging
>
>
> On Fri, Jan 17, 2003 at 12:29:16PM +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.

Re: multithreaded remote debugging

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 03:09:11PM +0100, Frank van Eijkelenburg wrote:
> > -----Original Message-----
> > From: gdb-owner@sources.redhat.com
> > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel Jacobowitz
> > Sent: vrijdag 17 januari 2003 14:54
> > To: Frank van Eijkelenburg
> > Cc: Gnu Debugger mailing list
> > Subject: Re: multithreaded remote debugging
> >
> >
> > On Fri, Jan 17, 2003 at 12:29:16PM +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.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: multithreaded remote debugging

[Frank van Eijkelenburg]

> > > > 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.

Re: multithreaded remote debugging

[Daniel Jacobowitz]

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.
-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: multithreaded remote debugging

[Frank van Eijkelenburg]

> -----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)

Re: multithreaded remote debugging

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 04:09:33PM +0100, Frank van Eijkelenburg wrote:
> 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?

Sometimes, but it doesn't seem to be the problem here.  I think your
binary has had some symbols removed, or something similar.  GDB is
looking for "__pthread_threads_events" and not finding it.

Are you running GDB with the file being debugged?  Does it have symbol
information?  The "in ??" is suspicious.

> 
> 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)
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: multithreaded remote debugging

[Frank van Eijkelenburg]

> On Fri, Jan 17, 2003 at 04:09:33PM +0100, Frank van Eijkelenburg wrote:
> > 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?
>
> Sometimes, but it doesn't seem to be the problem here.  I think your
> binary has had some symbols removed, or something similar.  GDB is
> looking for "__pthread_threads_events" and not finding it.
>
> Are you running GDB with the file being debugged?  Does it have symbol
> information?  The "in ??" is suspicious.
>

I'm not sure what you mean, but can you make your conlusions with this log:
(gdb) list
923             int iPoll = 0;
924
925             DebugInit(RmTrace, RmPanicHandler);
926
927             printf("Starting Terminal application %s\n", VERSION
VERSION_TEXT DEBUG_TEXT);
928
929             WritePID();
930
931             /* Catch Ctrl-C. Stop the program when it occurs. */
932             signal(SIGINT, SignalHandler);
(gdb) info line 923
Line 923 of "../src/sbiimain.c" starts at address 0x204926c <main+48> and
ends at 0x2049274 <main+56>.
(gdb) info symbol 0x204926c
main + 48 in section .text
(gdb)

Re: multithreaded remote debugging

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 04:28:17PM +0100, Frank van Eijkelenburg wrote:
> > On Fri, Jan 17, 2003 at 04:09:33PM +0100, Frank van Eijkelenburg wrote:
> > > 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?
> >
> > Sometimes, but it doesn't seem to be the problem here.  I think your
> > binary has had some symbols removed, or something similar.  GDB is
> > looking for "__pthread_threads_events" and not finding it.
> >
> > Are you running GDB with the file being debugged?  Does it have symbol
> > information?  The "in ??" is suspicious.
> >
> 
> I'm not sure what you mean, but can you make your conlusions with this log:
> (gdb) list
> 923             int iPoll = 0;
> 924
> 925             DebugInit(RmTrace, RmPanicHandler);
> 926
> 927             printf("Starting Terminal application %s\n", VERSION
> VERSION_TEXT DEBUG_TEXT);
> 928
> 929             WritePID();
> 930
> 931             /* Catch Ctrl-C. Stop the program when it occurs. */
> 932             signal(SIGINT, SignalHandler);
> (gdb) info line 923
> Line 923 of "../src/sbiimain.c" starts at address 0x204926c <main+48> and
> ends at 0x2049274 <main+56>.
> (gdb) info symbol 0x204926c
> main + 48 in section .text
> (gdb)

Try:
nm <binary> | grep __pthread_threads_events
nm <libpthread.a> | grep __pthread_threads_events

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer