This is the mail archive of the
mailing list for the GDB project.
Re: remote protocol extension for step out of range
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: remote protocol extension for step out of range
- From: jtc at redback dot com (J.T. Conklin)
- Date: 29 Jan 2001 14:21:11 -0800
- Cc: gdb at sourceware dot cygnus dot com
- References: <email@example.com> <3A75E47C.D2419ADA@cygnus.com>
- Reply-To: jtc at redback dot com
>>>>> "Andrew" == Andrew Cagney <firstname.lastname@example.org> writes:
>> Step-out-of-range only commands might look like:
>> 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.
Andrew> Would an addition to the breakpoint packet work? Rather than
Andrew> break when in this range, break when outside of this range.
If we tried, we could probably come up with something that would work.
However, the point at which we know the bounds of the step region is
"right before" we issue the step command. If we were to use a varient
of the breakpoint packet, we'd have to issue two commands. I'd rather
avoid this unnecessary command/response latency. After all, that is
the primary reason for this extension.
The only other option that appeals to me is to completely depricate
the step command and have a new command that supports either step or
step out of range depending on its arguments.