From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org, gdb-patches@sourceware.org
Subject: [rfa] gdbserver multiple register set issue: target description in remote_attach
Date: Thu, 08 May 2008 20:02:00 -0000 [thread overview]
Message-ID: <200805081829.m48ITkXu004692@d12av02.megacenter.de.ibm.com> (raw)
Hello,
another (potential) problem in gdbserver --multi mode. A second process that
is being attached to might have a different register set, and thus a different
XML target description. Now, the common attach code will re-query the target
description in any case. However, in the interval after the vAttach command
returns and before the description is read, GDB and gdbserver may be out of
sync about register sizes etc. In remote_open_1, the remote.c -for a similar
reason- calls target_find_description early.
While I was only able to see an actual bug due to this in a modified version of
GDB (that installs an extra target on the stack above the remote target), I think
it would be safer in any case for extended_remote_attach_1 to do the same as
remote_open_1 does and call target_find_description early.
What do you think? Would this be OK for mainline?
Tested on powerpc-linux and powerpc64-linux in local gdbserver mode.
Bye,
Ulrich
ChangeLog:
* remote.c (extended_remote_attach_1): Call target_find_description.
diff -urNp src-orig/gdb/remote.c src/gdb/remote.c
--- src-orig/gdb/remote.c 2008-04-20 17:22:14.000000000 +0200
+++ src/gdb/remote.c 2008-04-20 17:22:23.000000000 +0200
@@ -2840,6 +2840,7 @@ extended_remote_attach_1 (struct target_
struct remote_state *rs = get_remote_state ();
int pid;
char *dummy;
+ char *wait_status = NULL;
if (!args)
error_no_arg (_("process-id to attach"));
@@ -2863,8 +2864,9 @@ extended_remote_attach_1 (struct target_
printf_unfiltered (_("Attached to %s\n"),
target_pid_to_str (pid_to_ptid (pid)));
- /* We have a wait response; reuse it. */
- rs->cached_wait_status = 1;
+ /* Save the reply for later. */
+ wait_status = alloca (strlen (rs->buf) + 1);
+ strcpy (wait_status, rs->buf);
}
else if (remote_protocol_packets[PACKET_vAttach].support == PACKET_DISABLE)
error (_("This target does not support attaching to a process"));
@@ -2875,6 +2877,15 @@ extended_remote_attach_1 (struct target_
target_mark_running (target);
inferior_ptid = pid_to_ptid (pid);
attach_flag = 1;
+
+ /* Next, if the target can specify a description, read it. We do
+ this before anything involving memory or registers. */
+ target_find_description ();
+
+ /* Use the previously fetched status. */
+ gdb_assert (wait_status != NULL);
+ strcpy (rs->buf, wait_status);
+ rs->cached_wait_status = 1;
}
static void
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next reply other threads:[~2008-05-08 18:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 20:02 Ulrich Weigand [this message]
2008-05-08 21:19 ` Daniel Jacobowitz
2008-05-09 1:29 ` Ulrich Weigand
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=200805081829.m48ITkXu004692@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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