From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA/RFC: vCont for the remote protocol [client]
Date: Wed, 15 Oct 2003 00:15:00 -0000 [thread overview]
Message-ID: <3F8C917C.1080708@gnu.org> (raw)
In-Reply-To: <20030930211717.GB19869@nevyn.them.org>
[I think my GNU e-mail is down] [I'm also having trouble reading this
unified diff, so watch out :-)]
+/* Check for the availability of vCont. This function should also check
+ the response. */
see below ...
> static void
> -remote_resume (ptid_t ptid, int step, enum target_signal siggnal)
> +remote_vcont_probe (struct remote_state *rs, char *buf)
> {
> - struct remote_state *rs = get_remote_state ();
> - char *buf = alloca (rs->remote_packet_size);
> - int pid = PIDGET (ptid);
> - char *p;
> -
> - if (pid == -1)
> - set_thread (0, 0); /* run any thread */
> - else
> - set_thread (pid, 0); /* run this thread */
> -
> - last_sent_signal = siggnal;
> - last_sent_step = step;
> + strcpy (buf, "vCont?");
> + putpkt (buf);
> + getpkt (buf, rs->remote_packet_size, 0);
> + packet_ok (buf, &remote_protocol_vcont);
> +}
packet_ok will go through the path:
/* The packet may or may not be OK. Just assume it is */
return PACKET_OK;
Shouldn't remote_vcont_probe apply additional sanity checks. For
instance that the response is well formed, and that all the letters
[SCsc] appeared? If they are not all present, just mark the packet is
not supported for now. (But also comment this).
+static int
+remote_vcont_resume (ptid_t ptid, int step, enum target_signal siggnal)
What's the return value?
+{
+ struct remote_state *rs = get_remote_state ();
+ int pid = PIDGET (ptid);
+ char *buf = alloca (rs->remote_packet_size);
Rather than ALLOCA here, can you ...
+ /* If we could generate a wider range of packets, we'd have to worry
+ about overflowing BUF. Should there be a generic
+ "multi-part-packet" packet? */
+
+ if (PIDGET (inferior_ptid) == MAGIC_NULL_PID)
+ {
+ /* MAGIC_NULL_PTID means that we don't have any active threads, so we
+ don't have any PID numbers the inferior will understand. Make sure
+ to only send forms that do not specify a PID. */
+ if (step && siggnal != TARGET_SIGNAL_0)
+ sprintf (buf, "vCont;S%02x", siggnal);
... use XASPRINTF here (along with some sort of cleanup).
Otherwize ok.
Andrew
next prev parent reply other threads:[~2003-10-15 0:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 15:28 Daniel Jacobowitz
2003-09-30 21:17 ` Daniel Jacobowitz
2003-10-15 0:15 ` Andrew Cagney [this message]
2003-10-16 20:31 ` Daniel Jacobowitz
2003-10-16 21:18 ` Andrew Cagney
2003-10-16 22:14 ` Daniel Jacobowitz
2003-10-16 22:27 ` Andrew Cagney
2003-10-16 22:53 ` Daniel Jacobowitz
2003-12-02 16:07 ` [RFA] Remove some sprintfs from vCont client support Daniel Jacobowitz
2003-12-03 4:25 ` Andrew Cagney
2004-01-18 3:39 ` Daniel Jacobowitz
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=3F8C917C.1080708@gnu.org \
--to=cagney@gnu.org \
--cc=drow@mvista.com \
--cc=gdb-patches@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