Torubles with remote stub for m68k

Andrew Cagney
Tue Jun 25 13:43:00 GMT 2002

> (gdb) c
> Continuing.
> Sending packet: $Z0,3af78,2#7d...Ack
> Packet received: 
> Packet Z0 (software-breakpoint) is NOT supported
> Sending packet: $m3af78,2#34...Ack
> Packet received: 4ab9
> Sending packet: $X3af78,0:#57...Ack

> Packet received: OK
> binary downloading suppported by target
> Sending packet: $X3af78,2:NA#e8...Ack

Set breakpoint at address 3af78.

> Packet received: OK
> Sending packet: $Hc0#db...Ack
> Packet received: ENN
> Sending packet: $c#63...Ack
> Packet received: T05thread:9;
> [New Thread 9]
> Sending packet: $g#67...Ack
> Packet received: 00000000000000000000006300000000004b47b8000000000000000000000000000000000000000000012ca000012c240000000000000000005c34d4005c34c8000000000014a898000000000000000000000000000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff0000000000000000000000000000000000000000

For some reason here, GDB didn't pull all breakpoints.  GDB normally 
pulls all breakpoints as part of a stop.  I suspect this is why the 
breakpoint is still in memory when you go to SI - GDB doesn't think it 
needs to pull any breakpoints.

> Program received signal SIGTRAP, Trace/breakpoint trap.

Is the target sitting on a breakpoint?  If it is GDB should report that 
breakpoint but it hasn't.

What is the raw value of the PC as found in the G packet (rather than 
what $pc displays at this point?).  The m68k is one of the decr pc after 
break targets [true] so likely it is getting that wrong.


More information about the Gdb mailing list