[remote protocol] step range?

[Jason Molenda]

On Sep 4, 2008, at 7:38 PM, Michael Snyder wrote:

> I don't think that's necessarily true -- the remote agent
> could just do what gdb does, single-step repeatedly and
> check the stop pc against the range.

Yeah, that'll work as long as you have some form of single-instruction- 
step support in your target environment.  If not, then you'll need a  
disassembler to (a) determine the length of the current instruction so  
you can overwrite the next instruction with a trap opcode, and (b)  
determine if the current instruction branches/calls/jumps anywhere.   
It quickly becomes Complicated.  I'm assuming you have some form of  
single-instruction-step in the target you're interested in, otherwise  
I council against pursuing this. :)

For what it's worth we use the remote protocol for debugging  
applications on the iPhone / iPod Touch devices.  When we first got it  
up and running, we saw command-line level "step" commands taking  
multiple (4-5!) seconds to complete.  We optimized it to no end and  
got this down to something like .2 seconds without doing anything too  
weird to the protocol.  We didn't have any single-instruction-step  
feature so we didn't even consider trying to push range-stepping down  
to the device.

But I don't see any problems with adding this stepping capability for  
environments that could make use of it.

> Well, if the remote can deal with threads at all (eg. gdbserver),
> then it could probably treat this just as gdb would.  A preemptive
> stop in another thread would be outside the step range, therefore
> we would tell gdb that we stopped.

Since we've established that you must have single-instruction-step  
capability in the target to do this, I think it's safe to assume that  
only the current continue thread will execute.  But as you say, if the  
remote agent determines that it stopped in a different thread than it  
began the step, it can give up and return control to gdb.

J