Re: remote protocol extension for step out of range

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
> jtc> Step-out-of-range only commands might look like:
> jtc>
> jtc>         ENN,SS..SS,EE..EE[,AA...AA]
> jtc> or:
> jtc>         eSS...SS,EE..EE[,AA..AA]
> jtc>
> jtc> Which would step from the PC and repeat until it moved out of the
> jtc> range described by SS..SS and EE..EE.  I've also preserved the ability
> jtc> to set the initial PC like the existing step commands for parallelism;
> jtc> I don't expect that GDB will use it either.
> jtc>
> jtc> To be able to successfully probe for this command, there should be a
> jtc> return value.  An OK or EXX response should do.  Older stubs would
> jtc> return "" as they do for all unrecognized commands.
> 
> It turned out to be trival to implement the above.  I've enclosed a
> patch for review.  The guts are ~50 lines, including comments.  The
> rest is required for the CLI so the user can enable and disable the
> new packets.
> 
> I welcome any comments,

I'm wondering about is how this works in a threaded environment.  This
continuation is very thread unfriendly (so is the underlying code so I'm
fighting an up hill battle here :-).  That was the reason for thinking
of an explicit breakpoint packet - so it could eventually be bound to a
specific thread.  Given that this packet is mostly reflecting the way
the GDB works, I suspect doing this different is beyond the scope of
your proposed change.

How will this packet work with something like the sparc where, to do a
correct continue you need to set both PC and NPC.  Consequently a sparc
does a resume by setting PC/NPC with register-write packets and then
does the continue.

With regard to the syntax, can it be specified in a way that is
extensable?  The ``T'' reply packet can bundle up all sorts of
information.  If we're going to have a new continue packet can the
syntax be such that it allows similar extensions?

Dig dig dig.  I've a local stub that uses the T packet to send back
_all_ the registers (none of this ``Gg'' stuff :-).  It was also tweeked
to allow the syntax <RENUM>!<NETWORK-ORDERD-VALUE> instead of
``<REGNUM>=<TARGET-ORDERD-VALUE>''  Should the [eE] packet syntax mirror
that of the ``T'' reply?  Perhaphs not the register values but at least
the ability to be extensable?

	Andrew