This is the mail archive of the gdb@sourceware.cygnus.com 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 and CNTRL-C + X packet?


>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Hello, (Here's one for the remote-protocol police).  When GDB
Andrew> wants a remote target to stop it can either perform an
Andrew> out-of-band ``break'' or send the CNTRL-C character.

Andrew> Technically this makes a singe CNTRL-C a packet in its own
Andrew> right (arrg :-). 

I don't think it is any worse than the ACK ('+') and NAK ('-')
characters being single character packets.  On the other hand, I
happen to think that is pretty bad in itself.  Ideally all three 
would use the same framing as other command/response packets.

Andrew> Should the protocol specify that a CNTRL-C is
Andrew> only valid outside of other packets (such as X).

I'd recommend this.  Although I suspect that there are stubs that
catch ^C in the interrupt handler used by the debug transport I/O
device and forces target execution to halt regardless of whether 
it occurs inside or outside a packet.  This suggests that ^C is
another character that should be quoted in binary memory writes.

If we were writing the remote protocol today, I'd propose that the
step and continue commands return an 'OK' packet.  GDB could query the
target execution status with '?', which would be extended with a 'no
status to report' response.  So that GDB wouldn't have to constantly
poll the target, a target->host callback/command would be needed to
inform GDB that there is status to be retrieved.

With an asynchronous model, STOP would be just another command.  This
would also allow us to read the targets registers and memory with the
existing commands without stopping it, perhaps useful for tracepoints?

Andrew> Should it be sent within a proper packet (I suspect some
Andrew> existing targets would ignore it).

Hmm, don't know.  

A getpacket() that doesn't currently do anything special for ^C, would
no longer ignore it and would return the buffer to handle_exception().
It wouldn't match anything in the switch statement, and the stub would
return an empty packet.  If GDB is waiting for an execution status
response (SXX, TXX, W, X, etc.), it might get confused.

        --jtc

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