remote protocol extension for step out of range

[jtc at redback dot com (J.T. Conklin)]

As I mentioned a few weeks ago, I'd like to add the ability for
step-out-of range to the remote protocol.  While there are still some
unresolved issues about how the range limits should be obtained by the
to_resume vector function, in worst case I could do what the vxWorks
RDB back end does and access the globals step_range_start and
step_range_end.

The current remote protocol "step" command is 

        SNN[,AA..AA]
or:
        s[AA..AA]

The first form encodes a signal number to be delivered and an optional
address that becomes the new PC.  The second form only encodes the new
PC.  Note that while the protocol supports setting the PC, GDB does
not use it.

Unfortunately it would be difficult to extend either command to
contain a range because neither the sample stubs distribued with GDB
or gdbserver completely parse the step commands and return a failure
indication.  Without this, it's pretty much impossible to probe the
stub to see if it supports this extension.

Since that's not practical, I don't think there is any other solution
other than to create a new set of commands.  They could be a superset
of the existing step commands or be used only for step out of range.
I'm not sure which is better.

Step-out-of-range only commands might look like:

        ENN,SS..SS,EE..EE[,AA...AA]
or:
        eSS...SS,EE..EE[,AA..AA]

Which would step from the PC and repeat until it moved out of the
range described by SS..SS and EE..EE.  I've also preserved the ability
to set the initial PC like the existing step commands for parallelism;
I don't expect that GDB will use it either.

To be able to successfully probe for this command, there should be a
return value.  An OK or EXX response should do.  Older stubs would
return "" as they do for all unrecognized commands.

Btw, I chose 'E/e' because that was the only letter in the word 'step'
that isn't already used.

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks