From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21274 invoked by alias); 4 Feb 2009 00:49:18 -0000 Received: (qmail 21265 invoked by uid 22791); 4 Feb 2009 00:49:17 -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; Wed, 04 Feb 2009 00:49:12 +0000 Received: (qmail 10722 invoked from network); 4 Feb 2009 00:49:10 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Feb 2009 00:49:10 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [0/2] Inspect extra signal information Date: Wed, 04 Feb 2009 00:49:00 -0000 User-Agent: KMail/1.9.10 Cc: Daniel Jacobowitz , Ulrich Weigand References: <200902031501.49657.pedro@codesourcery.com> <200902031951.44699.pedro@codesourcery.com> <20090204002438.GA29944@caradoc.them.org> In-Reply-To: <20090204002438.GA29944@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902040049.10820.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/msg00084.txt.bz2 On Wednesday 04 February 2009 00:24:38, Daniel Jacobowitz wrote: > 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. A few emails ago I mentioned "if I make use of struct type/struct value if may not be bad, but, gdbserver can't use those..." :-), and I was also thinking of something similar, but simpler. I was thinking of building up a value with the 64-bit type (gdb knows how to build it already), and pass it the raw 64-bit data. Then build a new value with the 32-bit data, and iterate simulatenously in both values through each field and copy/convert each field to the 32-bit value, as appropriate. But as you say below, I don't like having two ways to do the same thing, given that something has to be done on the gdbserver side. > 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. That's my thinking too. I'm half through, let's see what comes out... > I vaguely remember having to do something similar for Solaris's > procfs. Yep. I remember that. It was related to that fact that auxv data in procfs is presented with a 64-bit layout to a 64-bit gdb, even if the inferior is 32-bit. If I'm not mistaken: 2008-05-04 Vladimir Prus ... * target.h (struct target_ops): New field to_auxv_parse. * auxv.c (default_auxv_parse): New, renamed from previous target_auxv_parse. (target_auxv_parse): Try to call target method. Fallback to default_auxv_parse if not found. * procfs.c (procfs_auxv_parse): New. (init_procfs_ops): On Solaris, in 64-bit mode, install procfs_auxv_parse. > Only biarch platforms would have this problem, and fortunately there > aren't too many. -- Pedro Alves