From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30107 invoked by alias); 12 May 2006 22:19:23 -0000 Received: (qmail 30094 invoked by uid 22791); 12 May 2006 22:19:23 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 22:19:21 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FefyJ-0002zd-R7; Fri, 12 May 2006 15:18:55 -0700 Date: Fri, 12 May 2006 22:32:00 -0000 Message-Id: <20060512.151851.65038908.davem@davemloft.net> To: drow@false.org Cc: mark.kettenis@xs4all.nl, fnf@specifix.com, gdb-patches@sourceware.org Subject: Re: [RFC] DWARF 2 address size != pointer size From: "David S. Miller" In-Reply-To: <20060512195634.GA16903@nevyn.them.org> References: <200605101424.11088.fnf@specifix.com> <200605121951.k4CJp1ao000358@elgar.sibelius.xs4all.nl> <20060512195634.GA16903@nevyn.them.org> X-Mailer: Mew version 4.2.53 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00269.txt.bz2 From: Daniel Jacobowitz Date: Fri, 12 May 2006 15:56:34 -0400 > It's a code model thing. It has 64-bit pointers, but all symbols are > 32-bit, and IIRC it actually uses 32-bit ELF. Sparc64 with -mcmodel=medlow is the same situation, but the DWARF address sizes are still 64-bit and don't change based upon the 64-bit code model selected. I guess this is a side effect of using the MIPS 32-bit ELF target rather than something explicit the MIPS backend of GCC is doing to tinker with the DWARF output format? Actually, there is a Sparc situation which is more like this MIPS case. For -mcpu=v8plus{,a,b} and friends, we're generating 32-bit code and using 32-bit SPARC ELF, but certain registers are available for full 64-bit integer operations (for "long long"). We don't handle this in GDB currently because there is no easy way to get at the full 64-bit register values in a 32-bit process with a 32-bit gdb. With a 64-bit GDB we can easily do this, and under Linux/Sparc there are special versions of the ptrace commands which allow passing 64-bit register values back and forth to/from a 32-bit debugger. I've always wanted to add support for that, but it's going to be real ugly stuff and take us away from the nice unified Sparc ptrace() support which several Sparc targets are sharing right now.