This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

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



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