From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: Two small remote protocol extensions
Date: Fri, 03 May 2002 14:28:00 -0000 [thread overview]
Message-ID: <20020503212803.GB27650@nevyn.them.org> (raw)
In-Reply-To: <3CD2D5EC.5020708@cygnus.com>
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
next prev parent reply other threads:[~2002-05-03 21:28 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-01 19:25 Daniel Jacobowitz
2002-05-02 8:38 ` Andrew Cagney
2002-05-02 8:52 ` Daniel Jacobowitz
2002-05-02 9:39 ` Andrew Cagney
2002-05-02 12:14 ` Daniel Jacobowitz
2002-05-02 12:22 ` Kevin Buettner
2002-05-02 12:34 ` Daniel Jacobowitz
2002-05-02 13:13 ` Andrew Cagney
2002-05-02 14:09 ` Daniel Jacobowitz
2002-05-03 11:24 ` Andrew Cagney
2002-05-03 14:28 ` Daniel Jacobowitz [this message]
2002-05-03 15:18 ` Andrew Cagney
2002-05-03 15:22 ` Daniel Jacobowitz
2002-05-04 19:59 ` Andrew Cagney
2002-05-02 13:13 ` Quality Quorum
2002-05-02 14:13 ` Daniel Jacobowitz
2002-05-03 13:07 ` Andrew Cagney
2002-08-16 7:30 ` Daniel Jacobowitz
2002-08-16 7:42 ` Andrew Cagney
2002-08-16 7:52 ` Daniel Jacobowitz
2002-08-16 8:21 ` Andrew Cagney
2002-08-22 19:23 ` Andrew Cagney
2002-08-22 19:36 ` Daniel Jacobowitz
2002-08-23 7:24 ` Quality Quorum
2002-08-23 7:26 ` Daniel Jacobowitz
2002-08-23 7:49 ` Quality Quorum
2002-08-23 8:57 ` Andrew Cagney
2002-08-23 11:16 ` Quality Quorum
2002-08-23 12:39 ` Andrew Cagney
2002-08-23 13:10 ` Quality Quorum
2002-08-27 20:23 ` Andrew Cagney
2002-08-28 8:31 ` Quality Quorum
2002-08-28 9:44 ` Andrew Cagney
2002-08-28 9:49 ` Daniel Jacobowitz
2002-08-22 21:08 ` Andrew Cagney
2002-08-23 5:44 ` Daniel Jacobowitz
2002-08-23 12:10 ` Andrew Cagney
2002-08-23 12:53 ` Andrew Cagney
2002-08-23 13:15 ` Daniel Jacobowitz
2002-08-27 21:07 ` Andrew Cagney
2002-08-28 6:33 ` Daniel Jacobowitz
2002-09-25 8:51 ` Daniel Jacobowitz
2002-09-25 11:17 ` Andrew Cagney
2002-09-26 18:39 ` Andrew Cagney
2002-09-26 18:48 ` Andrew Cagney
2003-06-29 7:51 ` Daniel Jacobowitz
2003-09-03 23:41 ` Andrew Cagney
2003-09-17 15:51 ` Daniel Jacobowitz
2003-09-17 16:19 ` Andrew Cagney
2003-09-17 16:23 ` Daniel Jacobowitz
2003-09-22 0:27 ` Andrew Cagney
2003-09-22 1:01 ` Daniel Jacobowitz
2003-09-22 3:02 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020503212803.GB27650@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox