Re: multithreaded remote debugging

[Daniel Jacobowitz <drow at mvista dot com>]

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