Re: Re: Remote Debugging Of Multithreaded Application on PPC 82xx

Re: Re: Remote Debugging Of Multithreaded Application on PPC 82xx

[Frank.Christ]

Hi Daniel,

Thanks for your quick answer! Unfortunately your PREPARE_TO_PROCEED patch
did not have any effect on my system. I still have the problem, that the
debugger
jumps to the main thread instead of stepping through the client thread.

In some older mailings I found a hint, that there might be a problem, when there
are printed question marks (??) when the debugger starts. When I connect to
the remote target, I get the following lines on the host side. Is this correct?

(gdb) target remote 172.20.62.126:2345
Remote debugging using 172.20.62.126:2345
0x30010464 in ?? ()
(gdb) cont

My Thread Librarys have the following Versions:
   libpthread-0.8.so
   libthread_db-1.0.so
Are there any problems with Library versions?

Thanks again,
Frank





Daniel Jacobowitz <drow@mvista.com> am 14.03.2003 15:17:38

An:   Frank Christ/RSBICK@RSBICK
cc:   gdb@sources.redhat.com

Thema:    Re: Remote Debugging Of Multithreaded Application on PPC 82xx



On Fri, Mar 14, 2003 at 03:03:25PM +0100, Frank.Christ@RSBICK.rohde-schwarz.com
wrote:
> I am trying to setup a remote debugging session, so that I can debug my
> multithreaded
> application running on PPC 82xx and use gdb on my Intel host (i686, SuSE 7.0).
>
> I downloaded gdb version 5.3 and compiled gdb on the host (with target
> powerpc-linux).
> I also cross-compiled gdbserver (with option powerpc-linux).
>
> I have /lib/libthread_db.so.1 on the 8xx
>   have the target filesystem layout available on the host
>   have solib-absolute-prefix set to point to the target libraries
> (solib-absolute-prefix=/opt/elinos/cdk/ppc/82xx/libc6/powerpc-linux)
>
> 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. I can put
> breakpoints in
> every thread and break into my code. "info threads" gives all my threads and
> everything
> seems fine.
>
> However:
> I can step through the main thread, but I cannot step through all my other
> threads. When
> I try to step with next in a client thread I get the following message:
>
> -------------------------------------
>  (gdb) next
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 1024]
> 0x0feee8a4 in nanosleep () from
> /opt/elinos/cdk/ppc/82xx/libc6/powerpc-linux/lib/libc.so.6
> ------------------------------------
>
> Any hints what my be wrong with my configuration?

You may want to try the PREPARE_TO_PROCEED patch which I posted to
gdb-patches yesterday; you can find the list archives on
http://sources.redhat.com/ml/gdb-patches/2003-03/.

There are also some bugs related to stepping alternate threads that
require a change to the remote protocol, but I didn't get a consensus
on how to solve them yet (and I ran out of time to pursue it; I'll try
again soon).

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Re: Remote Debugging Of Multithreaded Application on PPC 82xx

[Daniel Jacobowitz]

On Mon, Mar 17, 2003 at 01:30:34PM +0100, Frank.Christ@RSBICK.rohde-schwarz.com wrote:
> Hi Daniel,
> 
> Thanks for your quick answer! Unfortunately your PREPARE_TO_PROCEED patch
> did not have any effect on my system. I still have the problem, that the
> debugger
> jumps to the main thread instead of stepping through the client thread.
> 
> In some older mailings I found a hint, that there might be a problem, when there
> are printed question marks (??) when the debugger starts. When I connect to
> the remote target, I get the following lines on the host side. Is this correct?
> 
> (gdb) target remote 172.20.62.126:2345
> Remote debugging using 172.20.62.126:2345
> 0x30010464 in ?? ()

That's normal.

> (gdb) cont
> 
> My Thread Librarys have the following Versions:
>    libpthread-0.8.so
>    libthread_db-1.0.so
> Are there any problems with Library versions?

Probably not.  That's, what, glibc 2.1.3?

You'll need to give us a remote log (set debug remote 1).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer