This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
>
> I see; the only reason this is not an issue for 'T' responses is that
> the break should be ignored in that case.
The consequences of ignoring the break are harmless.
> I actually handle this
> correctly for TCP, if I get an interrupt while I'm expecting an ACK.
Careful. The behavour is undefined so there is nothing saying that your
implementation is correct.
> I don't know how this works on serial lines. The <BREAK> clobbers the
> traffic in the other direction?
Often a cntrl-c is sent instead of break. GDB can also NACK partial
packets. If you go through enough cases you find gdb can lock up (until
a timeout).
> Right now, waits for the ACK; it was easier and I'm more concerned
> about running threads than new threads. It would be more correct to
> release the thread first, in my opinion, but that conflicts with
> reporting "some threads stopped" to GDB. Depends which direction we
> go...
If you're holding onto the thread you're effectively synchronous. The
exchanges:
<- n<new-thread>
-> +
and
<- T00<new-thread>
-> +$C#..
<- +
are, only marginally different.
Should all threads be halted during this exchange? I think that is a
separate question.
enjoy,
Andrew