Stuart Hughes wrote:
> 
> Daniel Jacobowitz wrote:
> >
> 
> > > Sending packet: $m84c4,4#d0...Ack
> > > Packet received: 060000ea
> > > Sending packet: $M84c4,4:01009fef#15...Ack
> > > Packet received: OK
> > > Sending packet: $c#63...Ack
> > > Packet received: T050b:e4fcffbf;0d:d4fcffbf;0f:c4840000;
> >
> > Same, to 0x84c4.  Now this is the strange one.  What happened?  It
> > seems to have mispredicted the next instruction when placing the
> > breakpoint; the branch was presumably taken.
> >
> 
> Thanks for the pointer, I'll look into it and see if I can make any
> sense of it.
> 

Hi Daniel, 

Thanks for helping me track it down, I've modified the patch as you
suggested and it still works on my strong-arm target.

Some of the traffic for this problem went off the list, so to recap
here's the reasoning for what I've done:  When using gdb/gdbserver, when
stepping at branches, gdb asks for a register dump  by sending the 'g'
remote command, gdbsever in the case of arm, sends back the first 15
registers (gdbserver/linux-arm-low.c defines num_regs to 16, and so
gdbserver/linux-low.c:usr_fetch_inferior_registers actually asks for
registers 0->15  via the regmap in linux-arm-low.c).  If you look at
gdbsever/reg-arm.c, the original regmap is only requesting register
r0->pc, which doesn't include the status register.  Clearly, without the
status register being returned, it's not possible to correctly interpret
condition codes (for branches)

Thanks again for all those who helped.

Regards, Stuart