Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


             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