From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14829 invoked by alias); 4 Feb 2009 00:24:47 -0000 Received: (qmail 14820 invoked by uid 22791); 4 Feb 2009 00:24:47 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Feb 2009 00:24:41 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A72DC10A3D; Wed, 4 Feb 2009 00:24:39 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 8F82810A34; Wed, 4 Feb 2009 00:24:39 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LUVZG-0007s7-Mr; Tue, 03 Feb 2009 19:24:38 -0500 Date: Wed, 04 Feb 2009 00:24:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [0/2] Inspect extra signal information Message-ID: <20090204002438.GA29944@caradoc.them.org> Mail-Followup-To: Pedro Alves , Ulrich Weigand , gdb-patches@sourceware.org References: <200902031501.49657.pedro@codesourcery.com> <200902031824.22132.pedro@codesourcery.com> <20090203190432.GA11419@caradoc.them.org> <200902031951.44699.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902031951.44699.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00082.txt.bz2 On Tue, Feb 03, 2009 at 07:51:44PM +0000, Pedro Alves wrote: > I was thinking on doing this in the arch specific native files, e.g, > gdb/amd64-linux-nat.c, gdb/ppc-linux-nat.c, etc., and something similar in > gdbserver too. > > Just to make sure, where you perhaps thinking of something > entirely different? I don't see how to make this in a common native > file. What Doug described is pretty similar to what I had in mind; it does not fix the issue for gdbserver, but does for gdb. Read each field of the ptrace buffer, then use gdbarch to retrieve the type this would be expected to have in the inferior. Use gdb's type/value machinery to store the raw fields into the new value. Pass that value's contents back through the target layer to gdb, which will see the right values because it uses the same gdbarch to interpret them. Now, whether those hoops are worth it is another question. If we have to do this in gdbserver anyway, we could use the same method in gdb. I vaguely remember having to do something similar for Solaris's procfs. Only biarch platforms would have this problem, and fortunately there aren't too many. -- Daniel Jacobowitz CodeSourcery