From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19451 invoked by alias); 3 Feb 2009 16:42:37 -0000 Received: (qmail 19443 invoked by uid 22791); 3 Feb 2009 16:42:36 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.17.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Feb 2009 16:42:25 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id n13GgM9f027340 for ; Tue, 3 Feb 2009 16:42:22 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 v9.1) with ESMTP id n13GgM962207868 for ; Tue, 3 Feb 2009 17:42:22 +0100 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 n13GgLxv026182 for ; Tue, 3 Feb 2009 17:42:22 +0100 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 n13GgL35026175; Tue, 3 Feb 2009 17:42:21 +0100 Message-Id: <200902031642.n13GgL35026175@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 3 Feb 2009 17:42:21 +0100 Subject: Re: [0/2] Inspect extra signal information To: pedro@codesourcery.com (Pedro Alves) Date: Tue, 03 Feb 2009 16:42:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200902031501.49657.pedro@codesourcery.com> from "Pedro Alves" at Feb 03, 2009 03:01:49 PM 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: 2009-02/txt/msg00064.txt.bz2 Pedro Alves wrote: > Boo, turns out that I had tested on x86-64: > > - 64-bit gdb x 64-bit inferior, 64-bit kernel > > siginfo comes out with the 64-bit layout. > > - 32-bit gdb x 32-bit inferior, 64-bit kernel > > siginfo comes out with the 32-bit layout. > > > But, I thought I had, but I clearly didn't test before: > > - 64-bit gdb x 32-bit inferior, 64-bit kernel > > siginfo comes out with the 64-bit layout. > ^^^^^^ Huh. With bi-arch setups, I understand everything is currently supposed to be set up so that debugging a 32-bit program with a 64-bit GDB looks just the same as debugging it with a 32-bit GDB. The above would break that assumption: you see different types of siginfo depending on your host GDB. I'm not sure if that is really what we want ... On the other hand, it's going to be difficult to avoid. One way would be for the Linux native target to always return the 32-bit layout when debugging a 32-bit inferior; if necessary it would have to convert the data in-place before returning it (similar to how the native target today converts register contents to 32 bit even though the ptrace interface returns 64 bit values). > I was looking at target_gdbarch, and it doesn't seem to fit the > bill either. E.g., a biarch ppc64 gdbserver returns a 32-bit > target_arch if the inferior is 32-bit. That's actually an interesting question. The idea behind "target_gdbarch" is "the architecture implemented by the target debugger interface". In a bi-arch setup, the target today emulates a 32-bit target interface when debugging a 32-bit inferior, even when GDB itself is 64-bit. This is done by explicit conversion in the native target (see above). Before real multi-architecture support, there really was to other way to do it. However, once we get to full multi-arch, it might in fact be a more natural fit to model the bi-arch setup by having "target_gdbarch" indicate the actual bitness of the ptrace interface (i.e. 64-bit), while still setting the per-frame architecture of all frames to the appropriate 32-bit architecture ... This might allow us to get rid of some of the bi-arch special hacks in native target code. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com