This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[rfa] gdbserver multiple register set issue: target description in remote_attach
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org, gdb-patches at sourceware dot org
- Date: Thu, 8 May 2008 20:29:46 +0200 (CEST)
- Subject: [rfa] gdbserver multiple register set issue: target description in remote_attach
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