GDB 6.2.1 with powerpc platform and uclibc and user breakpoint problem

GDB 6.2.1 with powerpc platform and uclibc and user breakpoint problem

[Andrew de Quincey]

Hi, I've having some serious problems with GDB 6.2.1. I am remote debugging a ppc 405 
platform based on the latest uclibc snapshot. So GDB itself is running on i386 targetted at 
the ppc-405, whilst gdbserver is a native ppc-405 application running on the target platform.

Oh - gcc is v3.3.4, built along with uclibc using the "toolchain" scripts available on www.uclibc.org.

The symptoms are user breakpoints do not work. However, GDB internal breakpoints *do* 
work. I've verified that the kernel (2.4.20) responds correctly to breakpoints by adding in 
tracing to the trap handlers.

I can't believe this is a problem with gdb itself. And other people have uclibc working 
with GDB on other platforms. So my only conclusion is that I'm doing something really 
stupid - but I don't know what!

I built GDB with: "./configure --target=ppc-405-linux; make"
I build gdbserver with "CC=ppc-405-linux-gcc ./configure --host=ppc-405-linux; make"

The test program is as follows - it performs a small calculation then intentionally generates a 
segfault. I am putting a breakpoint on the main() function, so it should stop before the segfault. 
This does not happen.

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main(int argc, char* argv[])
{
   int64_t sum;
   int x;
   int y;
   char* tmp = (void*) 0;

   x = x * 20;
   y = x;
   
   *tmp = 0;
   
   sum = -2000;
   x = atoi(argv[1]);
   
   printf("%lli\n", sum >> x);
}

I should also mention that I cross compiled GDB for the target platform and ran it natively - 
with the same problem!!! I also tried gdb 6.1.1 just in case - the same results.

Oh, I've also tried putting breakpoints on other lines - not just on "main()" - they don't work either.

I added protocol tracing to gdbserver. In the following, RX is a packet received from gdb, 
whilst TX is a packet sent by gdbserver:

--- I connect to the remote target with target remote ip:port

RX: Hc-1
TX: OK
RX: qC
TX:
RX: qOffsets
TX:
RX: ?
TX: T0501:7ffffb70;40:3000108c;
RX: Hg0
TX: OK
RX: g
TX: 000000007ffffb7000000000000000000000000000000000000000000000000000000000000000000000000000000
RX: mfffffffc,c
TX: E01
RX: mfffffffc,c
TX: E01
RX: m10010904,b0
TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000
RX: qSymbol::
TX: OK                                                                                           

-- At this point, GDB stops at the _dl_boot function. I type "break main" and then "c"

RX: Z0,10000548,4
TX:
RX: m10000548,4
TX: 38000000
RX: X10000548,0:
TX:
RX: M10000548,4:7d821008
TX: OK

-- here GDB read the contents of 0x10000548 - my breakpoint - and replaces it
with the trap instruction (0x7d821008)

RX: m300018d4,4
TX: 801c005c
RX: M300018d4,4:7d821008
TX: OK

-- here GDB read the contents of 0x300018d4 - an internal breakpoint on the _dl_debug_state function - and replaces it
with the trap instruction (0x7d821008).

RX: vCont?
X: vCont;c;C;s;S
RX: vCont;c

-- this is my continue command. It runs until GDB hits the following breakpoint.

TX: T0501:7ffff4e0;40:300018d4;

-- this is the internal breakpoint on _dl_debug_state being triggered. I see this in my kernel
tracing in the trap handlers.

RX: m10000548,4
TX: 7d821008
RX: M10000548,4:38000000
TX: OK
RX: m300018d4,4
TX: 7d821008
RX: M300018d4,4:801c005c
TX: OK

-- GDB is clearing the breakpoints *INCLUDING MY USER BREAKPOINT* - it has removed the
trap instruction and set it back to 0x38000000. why is it doing this!?!

RX: m10010904,b0
TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000
RX: m30005004,4
TX: 00000000
RX: vCont;s
TX: T0b01:7ffffa60;40:1000056c;
RX: g
TX: 000000007ffffa6000000000000000017ffffb747ffffb7c1000036c1000089c3001d2730000000000000000300d0
RX: m30027074,c
TX: 480b5cb57c601b787c030378
RX: m7ffffa68,4
TX: 00000001
RX: m7ffffa6c,4
TX: 7ffffb74

-- GDB has fallen into the segmentation violation here. I type "c" to continue.

RX: m10000548,4
TX: 38000000
RX: M10000548,4:7d821008
TX: OK
RX: m300018d4,4
TX: 801c005c
RX: M300018d4,4:7d821008
TX: OK
RX: vCont;C0b

-- GDB restores the trap handlers. It seems to be restoring the right values - this time. 
The "RX: M10000548,4:7d821008" command is writing the  trap instruction back out to 
memory for my user breakpoint.

Can anyone suggest something I can try out?

Re: GDB 6.2.1 with powerpc platform and uclibc and user breakpoint problem

[Daniel Jacobowitz]

On Sat, Nov 06, 2004 at 02:34:45PM +0000, Andrew de Quincey wrote:
> -- this is the internal breakpoint on _dl_debug_state being triggered. I see this in my kernel
> tracing in the trap handlers.
> 
> RX: m10000548,4
> TX: 7d821008
> RX: M10000548,4:38000000
> TX: OK
> RX: m300018d4,4
> TX: 7d821008
> RX: M300018d4,4:801c005c
> TX: OK
> 
> -- GDB is clearing the breakpoints *INCLUDING MY USER BREAKPOINT* - it has removed the
> trap instruction and set it back to 0x38000000. why is it doing this!?!

So that it can step past the breakpoint.

> RX: m10010904,b0
> TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000
> RX: m30005004,4
> TX: 00000000
> RX: vCont;s

That's a step request.

> TX: T0b01:7ffffa60;40:1000056c;

That's a segfault.  Your kernel has failed to implement
PTRACE_SINGLESTEP correctly.  This is a common problem on older 4xx
kernels.

-- 
Daniel Jacobowitz

Re: GDB 6.2.1 with powerpc platform and uclibc and user breakpoint problem

[Andrew de Quincey]

On Sunday 07 Nov 2004 02:10, Daniel Jacobowitz wrote:
> On Sat, Nov 06, 2004 at 02:34:45PM +0000, Andrew de Quincey wrote:
> > -- this is the internal breakpoint on _dl_debug_state being triggered. I
> > see this in my kernel tracing in the trap handlers.
> >
> > RX: m10000548,4
> > TX: 7d821008
> > RX: M10000548,4:38000000
> > TX: OK
> > RX: m300018d4,4
> > TX: 7d821008
> > RX: M300018d4,4:801c005c
> > TX: OK
> >
> > -- GDB is clearing the breakpoints *INCLUDING MY USER BREAKPOINT* - it
> > has removed the trap instruction and set it back to 0x38000000. why is it
> > doing this!?!
>
> So that it can step past the breakpoint.
>
> > RX: m10010904,b0
> > TX:
> > 00000001000000010000000c1000036c0000000d1000089c0000000410000128000000051
> >00002680000000610000 RX: m30005004,4
> > TX: 00000000
> > RX: vCont;s
>
> That's a step request.
>
> > TX: T0b01:7ffffa60;40:1000056c;
>
> That's a segfault.  Your kernel has failed to implement
> PTRACE_SINGLESTEP correctly.  This is a common problem on older 4xx
> kernels.

Nice one! Thats it exactly. Thank you so much!

Interesting, this means our vendor has never had breakpoints working in GDB 
either. Hmmmm.....