From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3760 invoked by alias); 9 Nov 2012 05:26:27 -0000 Received: (qmail 3733 invoked by uid 22791); 9 Nov 2012 05:26:25 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com) (209.85.220.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Nov 2012 05:26:16 +0000 Received: by mail-pa0-f41.google.com with SMTP id fa10so2683550pad.0 for ; Thu, 08 Nov 2012 21:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr30112399pbc.105.1352438775716; Thu, 08 Nov 2012 21:26:15 -0800 (PST) Received: by 10.68.19.138 with HTTP; Thu, 8 Nov 2012 21:26:15 -0800 (PST) In-Reply-To: <20121109015149.13597.39322.stgit@brno.lan> References: <20121109015149.13597.39322.stgit@brno.lan> Date: Fri, 09 Nov 2012 05:26:00 -0000 Message-ID: Subject: Re: [PATCH] Multi-process + multi-arch: GDB From: "H.J. Lu" To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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: 2012-11/txt/msg00234.txt.bz2 On Thu, Nov 8, 2012 at 5:51 PM, Pedro Alves wrote: > This patch was part of a series I had posted back in > . I've > been distracted from that work since then, but since questions similar > or related to "how can we have more than one gdbarch" showed up on the > python architecture thread, I remembered I could push this part in > without the rest. The rest of the series depends on this (and will > need further porting work, since we have more gdbserver ports in the > tree now, and at least a couple more pending...), but this can go in > first and independently. It fixes the issue for native targets. > > I had a chance of chatting with Ulrich at FOSDEM earlier in the year, > and he also thought this was a good direction, so I'm putting it in. > > Although GDB currently supports debugging multiple inferiors > simultaneously, GDB is not prepared to handle the case of debugging > programs of different architectures (gdbarch's) simultaneously. A > simple example is debugging both a 32-bit and a 64-bit program > simultaneously on x86_64 (think following forks, and 32-bit and/or > 64-bit children being spawned), though more complicated examples could > be multi-core setups with processors on the same target (e.g., > x86_64 + ARM isn't uncommon these days). > > E.g., loading both a 64-bit inferior and a 32-bit inferior into GDB > shows (from the test in the patch): > > (gdb) file test64 > Reading symbols from test64...done. > (gdb) delete breakpoints > (gdb) break main > Breakpoint 1 at 0x40053a: file main.c, line 40. > (gdb) run > Starting program: test64 > > Breakpoint 1, main () at main.c:40 > 40 bar(); > (gdb) add-inferior > Added inferior 2 > inferior 2 > [Switching to inferior 2 [] ()] > (gdb) file test32 > warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Architecture of file not recognized. > > The "Architecture of file not recognized" warning is misleading. The > real issue is that target_gdbarch and the target description are > globals. So instead of fetching the target description for the 32-bit > process that was created for the `test32' program, the target > description that was previously fetched for inferior 1 (64-bit) is > assumed, and then things (rightfully) break, as it doesn't really > match inferior 2. > > This patch makes target_gdbarch (and the associated description) be > per-inferior instead. > > The new test fails without the rest of the patch. > > I've made the adjustment Yao pointed out in the old thread. > > (Re)tested on x86_64 Fedora 17, and checked in. > > gdb/ > 2012-11-09 Pedro Alves > > * gdbarch.sh (target_gdbarch) : Reimplement as macro. > (get_target_gdbarch) : New function. > (startup_gdbarch) : Declare. > (target_gdbarch): Delete. > (deprecated_target_gdbarch_select_hack): Set the > current inferior's gdbarch. > (get_target_gdbarch): New function. > * inferior.c: Include target-descriptions.h. > (free_inferior): Free target description info. > (add_inferior_with_spaces): Set the inferior's initial > architecture. > (clone_inferior_command): Copy the original inferior's target > description if it was user specified. > (initialize_inferiors): Add comment. > * inferior.h (struct target_desc_info): Forward declare. > (struct inferior) : New field. > * linux-nat.c: Include target-descriptions.h. > (linux_child_follow_fork): Copy the parent's architecture and > target description to the child. > * target-descriptions.c: Include inferior.h. > (struct target_desc_info): New structure, holding the equivalents > of ... > (target_desc_fetched, current_target_desc) > (target_description_filename): ... these removed globals. > (get_tdesc_info, target_desc_info_from_user_p) > (copy_inferior_target_desc_info, target_desc_info_free): New. > (target_desc_fetched, current_target_desc) > (target_description_filename): Reimplemented as convenience > macros. > (tdesc_filename_cmd_string): New global. > (set_tdesc_filename_cmd): Copy the string manipulated by the "set > tdescs filename ..." commands to the per-inferior equivalent. > (show_tdesc_filename_cmd): Get the value to show from the > per-inferior description filename. > (_initilize_target_descriptions): Change the "set/show tdesc > filename" commands' variable. > * target-descriptions.h (struct target_desc, struct target_desc_info) > (struct inferior): Forward declare. > (target_find_description, target_clear_description) > (target_current_description): Adjust comments. > (copy_inferior_target_desc_info, target_desc_info_free) > (target_desc_info_from_user_p). Declare. > Does it fix http://www.sourceware.org/bugzilla/show_bug.cgi?id=14306 -- H.J.