From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15449 invoked by alias); 3 Feb 2009 15:02:01 -0000 Received: (qmail 15319 invoked by uid 22791); 3 Feb 2009 15:02:01 -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 15:01:53 +0000 Received: (qmail 29872 invoked from network); 3 Feb 2009 15:01:51 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Feb 2009 15:01:51 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [0/2] Inspect extra signal information Date: Tue, 03 Feb 2009 15:02:00 -0000 User-Agent: KMail/1.9.10 References: <200901121846.51709.pedro@codesourcery.com> In-Reply-To: <200901121846.51709.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902031501.49657.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/msg00061.txt.bz2 On Monday 12 January 2009 18:46:51, Pedro Alves wrote: > =A0- Adds a new gdbarch method (get_siginfo_type) whose job is to return = a type > =A0 =A0suitable to print/inspect a TARGET_OBJECT_SIGNAL_INFO of a given a= rch. 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. ^^^^^^ The current patch assumed that PTRACE_GETSIGINFO would return an object with the layout of the 32-bit inferior, but, we actually get a 64-bit object. In sum, the data/type returned by PTRACE_GETSIGINFO is dependent on the arch of the *superior* (gdb). The current patch was using the gdbarch of the current frame, but, it is clear now that that is not the gdbarch we want. 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. (now that I'm looking at it, can't an inferior that started out as 32-bit call 64-bit code? If so, it seems that gdbserver and=20 target_gdbarch does not cope with that.) The options I'm seeing are either: - come up with a new target/host *interface* gdbarch, and pass that along in the target description. Use that gdbarch to build up the siginfo type, on the gdb side. - extend the xml type description support to be rich enough to describe the siginfo_t type (structs, typedefs, etc), and pass that along in the target description. Any suggestions? Other alternatives? --=20 Pedro Alves