[remote protocol] step range?

[remote protocol] step range?

[Michael Snyder]

Hey folks,

I know this subject has come up before...

What about a remote protocol command that says
"single step until you leave the range <begin> - <end>".

I suppose it would call for a new target vector, eg.
to_step_range, but it could be a great optimization for
slow remote targets, for doing statement-level stepping,
and would kinda fit right into infrun as if they were made
for each other.

Seems like the last discussion I can find was in 2001...

Would this for instance be a candidate for the new vCont extension?

Re: [remote protocol] step range?

[Jason Molenda]

On Sep 4, 2008, at 3:14 PM, Michael Snyder wrote:

> What about a remote protocol command that says
> "single step until you leave the range <begin> - <end>".

I wouldn't imagine any problem with such a packet - but it won't be  
useful on architectures that have variable length instructions (even  
ARM with its mix of ARM and Thumb opcodes) that don't have a hardware- 
supported single-instruction-step capability.  Your remote driver  
would need to contain a disassembler in those cases to do anything  
useful.

There is a lot of overhead and unnecessary communication over a  
typical remote protocol connection that you can eliminate with some  
effort.  But if the problem you're trying to solve is on a platform  
where single-instruction stepping is easy for the remote driver to do,  
this could be a reasonable alternate approach.  I suppose the most  
complicated thing you'd have to worry about is a remote target that  
has multiple threads, with those threads executing when you're trying  
to step through that range, and one of the other threads hitting a  
breakpoint or getting a signal.

Just my two cents,

J

Re: [remote protocol] step range?

[Michael Snyder]

Hey Jason!   ;-)

Jason Molenda wrote:
> On Sep 4, 2008, at 3:14 PM, Michael Snyder wrote:
> 
>> What about a remote protocol command that says
>> "single step until you leave the range <begin> - <end>".
> 
> I wouldn't imagine any problem with such a packet - but it won't be
> useful on architectures that have variable length instructions (even
> ARM with its mix of ARM and Thumb opcodes) that don't have a hardware-
> supported single-instruction-step capability.  Your remote driver
> would need to contain a disassembler in those cases to do anything
> useful.

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.

The idea is just to reduce the number of back-and-forth
transactions (but as it so happens, I'm playing with a
target where it would be a *huge* win.)


> There is a lot of overhead and unnecessary communication over a
> typical remote protocol connection that you can eliminate with some
> effort.  But if the problem you're trying to solve is on a platform
> where single-instruction stepping is easy for the remote driver to do,
> this could be a reasonable alternate approach.  I suppose the most
> complicated thing you'd have to worry about is a remote target that
> has multiple threads, with those threads executing when you're trying
> to step through that range, and one of the other threads hitting a
> breakpoint or getting a signal.

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.

This was, incidentally, the issue that the last thread on this
subject stalled on.  But I don't see why it isn't soluble...

Re: [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

Re: [remote protocol] step range?

[Michael Snyder]

Jason Molenda wrote:
> 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.

The first architecture I'll be interested in will be i386-linux.
So single-stepping on the target will be no problem.

If the target can't meet the request, it will just send back
an empty reply, same as always, and gdb will fall back to some
more generic method.

Re: [remote protocol] step range?

[Daniel Jacobowitz]

On Fri, Sep 05, 2008 at 05:16:15PM -0700, Jason Molenda wrote:
> 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.

I find this somewhat surprising - you don't need nearly as much of a
disassembler to do this for ARM as it sounds like from your comments.
I've written the code at least twice now, and for pre-Thumb-2 targets
it's quite straightforward.  And it saves enough round trips to be
a win, as long as you have somewhere closer to the target that can run
it.

> 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.

Well, in hosted environments the hardware single step bit is often
context-switched; e.g. %eflags.  Or in multi-core systems there may
actually be one per 'thread'.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [remote protocol] step range?

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Fri, Sep 05, 2008 at 05:16:15PM -0700, Jason Molenda wrote:
>> 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.
> 
> I find this somewhat surprising - you don't need nearly as much of a
> disassembler to do this for ARM as it sounds like from your comments.
> I've written the code at least twice now, and for pre-Thumb-2 targets
> it's quite straightforward.  And it saves enough round trips to be
> a win, as long as you have somewhere closer to the target that can run
> it.
> 
>> 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.
> 
> Well, in hosted environments the hardware single step bit is often
> context-switched; e.g. %eflags.  Or in multi-core systems there may
> actually be one per 'thread'.

Well you know, guys, it's always optional for a target
to implement a new protocol command.  If there's a target
for which this would be hard, or wouldn't gain you much,
you can always leave it un-implemented.

Re: [remote protocol] step range?

[Daniel Jacobowitz]

On Sat, Sep 06, 2008 at 05:33:59PM -0700, Michael Snyder wrote:
> Well you know, guys, it's always optional for a target
> to implement a new protocol command.  If there's a target
> for which this would be hard, or wouldn't gain you much,
> you can always leave it un-implemented.

Yes, I'm more concerned about e.g. inlining.  Basically, anything in
the inferior control loop that would be surprised by more than one
step.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [remote protocol] step range?

[Daniel Jacobowitz]

On Thu, Sep 04, 2008 at 03:14:07PM -0700, Michael Snyder wrote:
> Hey folks,
>
> I know this subject has come up before...
>
> What about a remote protocol command that says
> "single step until you leave the range <begin> - <end>".

This used to be on my todo list.  I saw some fundamental problem with
it and removed it... but I forgot to write down what the problem was
:-(

It might have been related to the inlined functions work.  After that,
it's tricky to figure out what the end range should be.

> Would this for instance be a candidate for the new vCont extension?

Yes, that'd be the way to add it.  (If you can still call it "new" at
this point...)

-- 
Daniel Jacobowitz
CodeSourcery