unable to debug remotely with threads on ppc target with gdb6.1/6.3

unable to debug remotely with threads on ppc target with gdb6.1/6.3

[Claudia Salzberg]

I sent this message out once already but it didnt get posted - suspecting 
a mail format issue I made sure its in text format so it should work 
now...sorry for the spam.

I have tried both gdb 6.1 the latest version (6.3) and am trying to debug 
a simple threaded program using pthreads remotely.   The target board is a 
440GP and the host is an x86 box.  I see references to similar problems in 
past posts from 12 2004 (
http://sourceware.org/ml/gdb/2004-12/msg00028.html) but did not see if a 
patch was created. 

This is my setup on the x86 side.  None of these steps have any ill 
effects on either side:
1) target remote 192.168.1.2:1234
2) add-symbol-file theadfooppc
3) directory /root                                      #where source file 
is located
4) set solib-absolute-prefix  /opt/xxx/ppc/ppc-linux/ 
5) set solib-search-path /opt/xxx/ppc/ppc-linux/lib     #this holds the 
libraries used when linking the program

The threaded program is very simple.  It creates two threads, calls 
pthread_join() on both, and then exits.  Upon issuing the 
pthread_create(), It specifies a function that prints a statement to 
stdout so that the thread may call it. (source show at end of message)

Then I set two breakpoints: one at main() and one at the function I pass 
pthread_create() so that the thread may execute it upon creation.  Upon my 
first 'c' I hit the first breakpoint, as expected.  With the second 'c' I 
receive the following message: "Program received signal SIG32, Real-time 
event 32.". Presumably, this is when the first pthread_create() gets 
called.  With the third 'c'  I receive the following message: "Program 
received signal SIGTRAP, Trace/breakpoint trap.".  At this point if I do 
'info b' I get the following breakdown:

(gdb) info b
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x10000530 in main at /root/threadfoo.c:10
        breakpoint already hit 1 time
2   breakpoint     keep y   0x100005ec in print_message_function
                                       at /root/threadfoo.c:34


Notice I have not yet reached my second breakpoint...If I do an 'info 
thread' I only get the original thread listed:

(gdb) info thread
  1 Thread 7576  0x0ffd1efc in ?? ()

With my fourth 'c' gdb says 'Continuing.' and pretty much hangs there.  I 
am able to ^C out of there and at that point it tells me the program is 
still running if I ask it to quit.

Next I tried another scenario...setting a breakpoint on pthread_create 
itself.  The setup is the same as above and I set the breakpoint on main 
as well.  When I do an 'info b' I get the following:

(gdb) info b
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x10000530 in main at /root/threadfoo.c:10
2   breakpoint     keep y   0x10010a6c <pthread_create>

I can 'c' through the code and hit the breakpoints appropriately.  The 
program runs through to termination.  However, an 'info threads' never 
yields anything but the first and original thread. 

Another scenario involved adding 'handle SIG32 nostop'.  In this case 
after the first of two threads is created (and I hit that breakpoint) I 
get the following:

Breakpoint 2, 0x10010a6c in ?? ()
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.

Program received signal SIG32, Real-time event 32.

Program received signal SIG32, Real-time event 32.

Program exited normally.

I do not hit the second breakpoint at the next pthread_create.

In either of the cases I never receive the "[Switching to thread X]" 
messages.

I include the complete output for the two scenarios in case it helps.  Any 
feedback would help.  Thank you,

Claudia Salzberg
Linux Technology Center
salzberg@us.ibm.com

First Scenario
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

x86:
======================================
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "--host=i686-suse-linux --target=ppc-linux".
(gdb) target remote 102.168.1.2:1234
102.168.1.2:1234: Interrupted system call.
(gdb) Quit
(gdb) target remote 192.168.1.2:1234
Remote debugging using 192.168.1.2:1234
0x3000f904 in ?? ()
(gdb) add-symbol-file /root/threadfooppc
add symbol table from file "/root/threadfooppc" at
(y or n) y
Reading symbols from /root/threadfooppc...done.
(gdb) directory /root/
Source directories searched: /root:$cdir:$cwd
(gdb) set solib-absolute-prefix /opt/xxx/ppc/ppc-linux/
(gdb) set solib-search-path /opt/xxx/ppc/ppc-linux/lib/
(gdb) b main
Breakpoint 1 at 0x10000530: file /root/threadfoo.c, line 10.
(gdb) b print_message_function
Breakpoint 2 at 0x100005ec: file /root/threadfoo.c, line 34.
(gdb) c
Continuing.

Breakpoint 1, main () at /root/threadfoo.c:10
warning: Source file is more recent than executable.

10           char *message1 = "Thread 1";
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x0feb65e4 in ?? ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0feb65e4 in ?? ()
(gdb) c
Continuing.


ppc side
=====================================================================
gdbserver 192.168.1.1:1234 threadfooppc
Process threadfooppc created; pid = 7824
Listening on port 1234
Remote debugging from host 192.168.1.1

Second Scenario
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
x86:
======================================
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "--host=i686-suse-linux --target=ppc-linux".
(gdb) target remote 192.168.1.2:1234
Remote debugging using 192.168.1.2:1234
0x3000f904 in ?? ()
(gdb) add-symbol-file /root/threadfooppc
add symbol table from file "/root/threadfooppc" at
(y or n) y
Reading symbols from /root/threadfooppc...done.
(gdb) directory /root/
Source directories searched: /root:$cdir:$cwd
(gdb) set solib-search-path /opt/xxx/ppc/ppc-linux/lib/
(gdb) set solib-absolute-prefix /opt/xxx/ppc/ppc-linux/
(gdb) b main
Breakpoint 1 at 0x10000530: file /root/threadfoo.c, line 10.
(gdb) b pthread_create
Breakpoint 2 at 0x10010a6c
(gdb) c
Continuing.

Breakpoint 1, main () at /root/threadfoo.c:10
warning: Source file is more recent than executable.

10           char *message1 = "Thread 1";
(gdb) c
Continuing.

Breakpoint 2, 0x10010a6c in ?? ()
(gdb) info thread
  1 Thread 7819  0x10010a6c in ?? ()
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x0feb65e4 in ?? ()
(gdb) info thread
  1 Thread 7819  0x0feb65e4 in ?? ()
(gdb) c
Continuing.

Breakpoint 2, 0x10010a6c in ?? ()
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x0feb65e4 in ?? ()
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x0feb65e4 in ?? ()
(gdb) c
Continuing.

Program exited normally.
(gdb)

ppc side
=====================================================================

> gdbserver 192.168.1.1:1234 threadfooppc
Process threadfooppc created; pid = 7819
Listening on port 1234
Remote debugging from host 192.168.1.1
Thread 1
Thread 2
Thread 1 returns: 0
Thread 2 returns: 0

Child exited with retcode = 0

Child exited with status 0
GDBserver exiting

Re: unable to debug remotely with threads on ppc target with gdb6.1/6.3

[Daniel Jacobowitz]

On Mon, Apr 11, 2005 at 11:29:19AM -0500, Claudia Salzberg wrote:
> I sent this message out once already but it didnt get posted - suspecting 
> a mail format issue I made sure its in text format so it should work 
> now...sorry for the spam.
> 
> I have tried both gdb 6.1 the latest version (6.3) and am trying to debug 
> a simple threaded program using pthreads remotely.   The target board is a 
> 440GP and the host is an x86 box.  I see references to similar problems in 
> past posts from 12 2004 (
> http://sourceware.org/ml/gdb/2004-12/msg00028.html) but did not see if a 
> patch was created. 
> 
> This is my setup on the x86 side.  None of these steps have any ill 
> effects on either side:
> 1) target remote 192.168.1.2:1234
> 2) add-symbol-file theadfooppc

Don't do that.  Use the file command (before connecting), not
add-symbol-file; it does not do what you think it does.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: unable to debug remotely with threads on ppc target with gdb6.1/6.3

[Daniel THOMPSON]

Claudia Salzberg wrote:
> I have tried both gdb 6.1 the latest version (6.3) and am trying to debug 
> a simple threaded program using pthreads remotely.   The target board is a 
> 440GP and the host is an x86 box.  I see references to similar problems in 
> past posts from 12 2004 (
> http://sourceware.org/ml/gdb/2004-12/msg00028.html) but did not see if a 
> patch was created.

No I am not aware of any patch fixing this issue.

The problem (as the thread says) is that ps_lgetregs is not implemented 
inside the gdbserver on PPC (or any other machine that uses 
PEEKUSER/POKEUSER to access its register sets).

You should be able to jury rig a version by copying the code in 
ppc-linux-nat.c:fill_gregset() into the ps_lgetregs function and 
modifying the code to target the gdbserver register cache rather then 
the gdb register cache.

There is, of course, a proper to way to do the above but you might want 
to confirm the above works first ;-)

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

Re: unable to debug remotely with threads on ppc target with gdb6.1/6.3

[Daniel Jacobowitz]

On Tue, Apr 12, 2005 at 08:52:38AM +0100, Daniel THOMPSON wrote:
> Claudia Salzberg wrote:
> >I have tried both gdb 6.1 the latest version (6.3) and am trying to debug 
> >a simple threaded program using pthreads remotely.   The target board is a 
> >440GP and the host is an x86 box.  I see references to similar problems in 
> >past posts from 12 2004 (
> >http://sourceware.org/ml/gdb/2004-12/msg00028.html) but did not see if a 
> >patch was created.
> 
> No I am not aware of any patch fixing this issue.
> 
> The problem (as the thread says) is that ps_lgetregs is not implemented 
> inside the gdbserver on PPC (or any other machine that uses 
> PEEKUSER/POKEUSER to access its register sets).
> 
> You should be able to jury rig a version by copying the code in 
> ppc-linux-nat.c:fill_gregset() into the ps_lgetregs function and 
> modifying the code to target the gdbserver register cache rather then 
> the gdb register cache.
> 
> There is, of course, a proper to way to do the above but you might want 
> to confirm the above works first ;-)

That's not Claudia's problem; the above only applies to NPTL, and she
appears to be using LinuxThreads from the error logs.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: unable to debug remotely with threads on ppc target with gdb6.1/6.3

[Claudia Salzberg]

>That's not Claudia's problem; the above only applies to NPTL, and she
>appears to be using LinuxThreads from the error logs.

Indeed I was misusing the commands to specify files.  The command 'file' 
cannot be used after connecting from gdb to a remoter gdbserver since the 
program is considered at that point to be running.  Because of this I used 
'add-symbol-file' which purportedly (or so I thought) allowed me to add a 
symbol file to an already running process.  However, this command should 
be used when the file specified has already been dynamically loaded 
(perhaps when a stripped executable is being run?).  Not sure how it works 
internally yet but the point is the 'file' command should be used to read 
symbols.  When using gdbserver, this command should be used prior to 
connecting remotely to the server to avoid the 'program already running' 
complaint.

Thanks for your help!  (now I'm tempted to try using NPTL ;) )

Claudia A. Salzberg
Linux Technology Center
salzberg@us.ibm.com