From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1611 invoked by alias); 8 May 2008 18:30:22 -0000 Received: (qmail 1597 invoked by uid 22791); 8 May 2008 18:30:21 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 May 2008 18:29:50 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m48ITlvV154444 for ; Thu, 8 May 2008 18:29:47 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m48ITldm4219112 for ; Thu, 8 May 2008 20:29:47 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m48ITksn004695 for ; Thu, 8 May 2008 20:29:47 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m48ITkXu004692; Thu, 8 May 2008 20:29:46 +0200 Message-Id: <200805081829.m48ITkXu004692@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 8 May 2008 20:29:46 +0200 Subject: [rfa] gdbserver multiple register set issue: target description in remote_attach To: drow@false.org, gdb-patches@sourceware.org Date: Thu, 08 May 2008 20:02:00 -0000 From: "Ulrich Weigand" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00286.txt.bz2 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