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


On Fri, May 03, 2002 at 02:24:44PM -0400, Andrew Cagney wrote:
> >On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote:
> >
> >>>These are threading information packets.  They are completely optional,
> >>>and I believe that they are of an appropriate nature for the
> >>>environments which support it; such systems generally:
> >
> >>
> >>Optional or not, it needs to be reliable.  You need to be able to run a 
> >>test cases 1000 times and have it pass 1000 times.
> >
> >
> >I really do not see what is unreliable here.  They're still ACKed...
> 
> Not necessarily.
> 
> What should happen if, at the same time as the target is creating / 
> sending an O packet, GDB sends a <BREAK>?  The protocol spec says nothing.
> 
> I believe, to define this, one would end up specifying a new protocol.

I see; the only reason this is not an issue for 'T' responses is that
the break should be ignored in that case.  I actually handle this
correctly for TCP, if I get an interrupt while I'm expecting an ACK.

I don't know how this works on serial lines.  The <BREAK> clobbers the
traffic in the other direction?

> In the mean time, the existing protocol remains ``synchronous''.  GDB 
> sends a request, the target replies.  At any time either GDB, xor the 
> target is in control.

.. sort of; see above in that GDB is already in getpkt () when these
n/x packets are received.  So it thinks the target is in control. 
Asynchronous breaks are a separate problem.

> Out of interest, does the n/x packet code in gdbserver, let go of a 
> created thread immediatly or does it wait until it has received the ack?

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

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


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