RE: Error running remote gdb

[Michael Snyder <Michael dot Snyder at palmsource dot com>]

On Wed, 2006-08-30 at 17:38 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
>  >  
> >> >>  
> >> >> Hi
> >> >> On our custome based powerpc we are running Linux 2.6.11.
> >> >> I am trying to run a sample debug session with gdbserver.
> >> >>  
> >> >> On target board I typed:
> >> >> gdbserver <host ip address>:portno <test program>
> >> >>  
> >> >> Then on host system I  typed:
> >> >> gdb <test program>
> >> >> gdb> target extended-remote <target IP addr>:portno b main cont
> >> >>  
> >> >> Then I got the following error on my host; Ignoring packet erro, 
> >> >> continuing...
> >> >> Ignoring packet erro, continuing...
> >> >> Reply contains invalid hex digit 116
> >> 
> >> >Something timed out.  Try "set debug remote 1" to see what's
> happening.
> >> I did that Now I see some ACK messages on my system.
> >
> >Please try the above command *before* connecting to the target, then
> connect, and send us the result (cut and >>
> paste).
> 
> 
> Here is the output, thanks:

So, first of all, it looks like you're no longer getting the error
  Ignoring packet error, continuing...
  Reply contains invalid hex digit 116

as in your first message.  Is that correct?  
As a point of interest, do we know what changed?

In your first msg, you said that at no point were you able
to set breakpoints and run the application.  That seems to
have changed too -- correct?

Just trying to keep up...

> % gdb test
> GNU gdb 6.5
> Copyright (C) 2006 Free Software Foundation, Inc.
[...]
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=powerpc-linux-gnuspe"...
> (gdb) set debug remote 1
> (gdb) target extended-remote 172.28.176.142:2001 
> Remote debugging using 172.28.176.142:2001
> Sending packet: $Hc-1#09...Ack
> Packet received: E01

OK -- the above is unimportant (has to do with threads).

[...]
> Sending packet: $?#3f...Ack
> Packet received: T0501:7ffffdb0;40:30010390;

So here is GDB asking the target "what's your stop status?"

And the target replies "I'm stopped for a SIGTRAP event
(a default debugger event), and I have the following 
register values:

Register 01: 7ffffdb0
Register 40: 30010390

I'm not looking at my PPC spec, but I'm guessing that 
Reg01 is the stack pointer and reg40 is the PC.  So the
target says it is at PC address 0x30010390.

Presumably that's in the start-up code.


> 0x30010390 in ?? ()

So here is GDB reporting that the target is stopped at 
instruction address 0x30010390, and that GDB doesn't have
any symbols at that address.  No surprise.

> Sending packet: $!#21...Ack
> Packet received: T0501:7ffffdb0;40:30010390;

Same pc and frame pointer.

[...]
> (gdb) b main
> Sending packet: $m10000544,4#5b...Ack
> Packet received: 9421ffd0
> Sending packet: $m10000548,4#5f...Ack
> Packet received: 7c0802a6
> Sending packet: $m1000054c,4#8a...Ack
> Packet received: 93810020
> Sending packet: $m10000550,4#58...Ack
> Packet received: 93a10024
> Sending packet: $m10000554,4#5c...Ack
> Packet received: 93e1002c
> Sending packet: $m10000558,4#60...Ack
> Packet received: 90010034
> Sending packet: $m1000055c,4#8b...Ack
> Packet received: 7c3f0b78
> Breakpoint 1 at 0x10000560: file test.c, line 9.

So, you asked for a breakpoint at main, and gdb acknowledges
setting your breakpoint at address 0x10000560, test.c line 9.

> (gdb) cont
> Continuing.

gdb acknowledges the continue request.

> Sending packet: $Z0,3000ce98,4#12...Ack
> Packet received: 
> Packet Z0 (software-breakpoint) is NOT supported
> Sending packet: $m3000ce98,4#c9...Ack
> Packet received: 9421fff0
> Sending packet: $X3000ce98,0:#ea...Ack
> Packet received: 
> binary downloading NOT suppported by target
> Sending packet: $M3000ce98,4:7d821008#b1...Ack
> Packet received: OK

gdb sets a breakpoint at 0x3000ce98.  
I'm not sure why it's doing that.
Must be the thread-event breakpoint.

> Sending packet: $m10000560,4#59...Ack
> Packet received: 48000181
> Sending packet: $M10000560,4:7d821008#41...Ack
> Packet received: OK

gdb sets a breakpoint at 0x10000560 (main, line 9).

> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> Packet received: T0501:7ffff850;40:3000ce98;

gdb asks the target to continue.  Target continues, 
then informs gdb "I hit a breakpoint at 0x3000ce98".

This is the first breakpoint that gdb set, above.
I'm pretty sure now that it's the thread event breakpoint.


> Sending packet: $m3000ce98,4#c9...Ack
> Packet received: 7d821008
> Sending packet: $M3000ce98,4:9421fff0#15...Ack
> Packet received: OK
> Sending packet: $m10000560,4#59...Ack
> Packet received: 7d821008
> Sending packet: $M10000560,4:48000181#09...Ack
> Packet received: OK

gdb removes the two breakpoints (the one at main, and this one).

[...]

gdb does a bunch of memory reads, probably grokking the 
target's thread tables.

> Sending packet: $vCont;s#b8...Ack
> Packet received: T0501:7ffff840;40:3000ce9c;thread:6098;
> [New thread 24728]

Finally gdb continues, the target reports another breakpoint
event in the thread library code, and gdb reports the detection
of a thread ID -- 24728.

> Sending packet: $p40#d4...Ack
> Packet received: 
> Sending packet: $g#67...Ack
> Packet received:
> 000000017ffff8403001362430026f5430001e9c0000000c000000050000001e00000000
> 000000000000000430026f54300041e0100262401fe7d500100c1808100c0088ffffffff
> ffffffff0000000000000000000000000000000700000000000000000000000000000003
> ffffffff0000000030026a78300263fc7ffff85000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000003000ce9c0202d00022000222
> 3000421430010e182000000000000000

Here, for the first time, gdb has requested the entire contents of
all target registers.  Note, I don't see any complaints about 
mis-matched packet sizes.

> Sending packet: $m3000ce98,4#c9...Ack
> Packet received: 9421fff0
> Sending packet: $M3000ce98,4:7d821008#b1...Ack
> Packet received: OK
> Sending packet: $m10000560,4#59...Ack
> Packet received: 48000181
> Sending packet: $M10000560,4:7d821008#41...Ack
> Packet received: OK
> Sending packet: $vCont;c#a8...Ack
> Packet received: T0501:7ffffd70;40:3000ce98;thread:6098;

gdb resets the breakpoints and continues.  The target
reports another breakpoint event at the thread library
location.  More memory reads follow.  This happens several
more times, so I'm going to skip ahead.

[...]


> Sending packet: $M3000ce98,4:7d821008#b1...Ack
> Packet received: OK
> Sending packet: $m10000560,4#59...Ack
> Packet received: 48000181
> Sending packet: $M10000560,4:7d821008#41...Ack
> Packet received: OK
> Sending packet: $vCont;c#a8...Ack
> Packet received: T0501:7ffffd30;40:10000560;thread:6098;
> [Switching to thread 24728]

OK, we've replaced the breakpoints and continued again.
Finally, the target reports a breakpoint event at main
(0x10000560), hit by the main thread (24728).


> Breakpoint 1, main () at test.c:9
> 9         set_mysignals();     /* Step III */ 
> (gdb) where
> #0  main () at test.c:9

gdb stops and reports we are now at line 9 of test.c.

> (gdb) n

OK, a better choice at this point might have been "step".
"Next" is more complicated.  Since you said "next", gdb
must first grok the stack frame, which you see by the next
sequence of memory and register reads.

> Sending packet: $m10000544,4#5b...Ack
> Packet received: 9421ffd0
> Sending packet: $m10000548,4#5f...Ack
> Packet received: 7c0802a6
> Sending packet: $m1000054c,4#8a...Ack
> Packet received: 93810020
> Sending packet: $m10000550,4#58...Ack
> Packet received: 93a10024
> Sending packet: $m10000554,4#5c...Ack
> Packet received: 93e1002c
> Sending packet: $m10000558,4#60...Ack
> Packet received: 90010034
> Sending packet: $m1000055c,4#8b...Ack
> Packet received: 7c3f0b78
> Sending packet: $m7ffffd30,4#63...Ack
> Packet received: 7ffffd60
> Sending packet: $g#67...Ack
> Packet received:
> 0fe3a0c47ffffd300ffac5c0000000017ffffdb47ffffdbc7ffffdfc3000ca747ffffda0
> 0ff7c360000000001001000030017000100195601fe7d500100c1808100c0088ffffffff
> ffffffff00000000000000000000000000000000100c10e800000000100005447ffffdfc
> 10000f5810000fe4000000010ff79ec07ffffd3000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000100005600202d00022000422
> 0fe3a0c40fe39f040000000000000000
> Sending packet: $m3000ce98,4#c9...Ack
> Packet received: 9421fff0
> Sending packet: $M3000ce98,4:7d821008#b1...Ack
> Packet received: OK
> Sending packet: $m10000560,4#59...Ack
> Packet received: 48000181
> Sending packet: $M10000560,4:7d821008#41...Ack
> Packet received: OK
> Sending packet: $vCont;s:6098;c#67...Ack

Finally, gdb restores the breakpoints and tells the target
to continue.

> Packet received: T0501:7ffffd30;40:10000560;thread:6098;

Whereupon we immediately hit the breakpoint at main.
This is where we went wrong.  This shouldn't have happened.

This is where I have to admit that I don't know the exact
semantics of the vCont message.  Over to you, Daniel?