From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6498 invoked by alias); 3 Feb 2009 18:23:20 -0000 Received: (qmail 6486 invoked by uid 22791); 3 Feb 2009 18:23:19 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Feb 2009 18:23:13 +0000 Received: (qmail 18923 invoked from network); 3 Feb 2009 18:23:07 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Feb 2009 18:23:07 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [0/2] Inspect extra signal information Date: Tue, 03 Feb 2009 18:23:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" References: <200902031642.n13GgL35026175@d12av02.megacenter.de.ibm.com> In-Reply-To: <200902031642.n13GgL35026175@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902031823.06618.pedro@codesourcery.com> 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: 2009-02/txt/msg00072.txt.bz2 On Tuesday 03 February 2009 16:42:21, Ulrich Weigand wrote: > Pedro Alves wrote: > > 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 ... Right, I'm not sure either. > 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 guess I should try this. > > 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). The only weird case I can think of, if when you have an inferior that can do mode switching, and the siginfo_t type is different in different modes. In this case, there'd better be a single siginfo_t layout for all modes, otherwise you get funny cases. Say, a signal handler installed in code that runs mode x-bit, but the signal was raised while running code in mode y-bit. Without kernel help, GDB can't know the correct layout of the siginfo_t object the inferior will see in the signal handler. I don't think we can see that happen on linux, though, so on the fly conversion out of ptrace sounds like a good option. Let's see if it doesn't come out looking too ugly. If I make use of struct type/struct value if may not be bad, but, gdbserver can't use those... > 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. That's actually what I initially thought target_gdbarch was reporting. Full multi-arch is something that is also interesting for multi-process. E.g, a bi-arch gdbserver, that supports multi-process has issues, when trying to debug simultaneously 32-bit and 64-bit inferiors. In this case, we have one target interface active (remote) and one target_gdbarch. Since the register layouts in the protocol aren't dynamic depending on the inferior (after the first inferior), on the multi-process branch, gdbserver only allows debugging multiple inferiors if they're of the same arch. current_gdbarch of course bites back in this scenario as well. BTW, what is the status of your per-frame gdbarch patches submitted a while ago? -- Pedro Alves