This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: remote protocol extension for step out of range

>>>>> "Andrew" == Andrew Cagney <> writes:
Andrew> The new packet expects an immediate response.  The remote
Andrew> protocol could have gone in two different directions here -
Andrew> drop the ack, always require the ack - and you've chosen the
Andrew> later and that definitly doesn't worry me :-)
Andrew> What I'm trying to understand is how this packet will interact
Andrew> with other things such as that out-of-band output (``O'')
Andrew> packet that comes from the target.  Ditto for an input packet
Andrew> if that is ever created.

Note that the response from new packet(s) indicate whether the packet
was received and parsed correctly.  It does not contain the result of
the step.

If GDB receives an OK response, it knows the debug agent has started
the target executing.  GDB will then wait for status from the target.
This could be an indication that the steps have continued and the PC
is now out of bounds, it could be a breakpoint, it could be a ``O''
packet, etc.

While I don't do this myself, one way to think about it is that these
new command packets have two responses (possibly more, when the ``O''
packets are taken into consideration).  I tend to think of the 'S', 
'T', 'W', 'X', 'O' responses as asyncronous notifications of target 
state, and that the existing 'c', 'C', 's', and 'S' commands screwed
up by not requiring a command response.

For an Input packet, the debug agent would have to support some sort
of asyncronous packet processing (otherwise we couldn't send input
when the target is running).  Handling the same while stepping in a
range would be no different IMO.


J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]