From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28497 invoked by alias); 12 May 2006 19:51:14 -0000 Received: (qmail 28482 invoked by uid 22791); 12 May 2006 19:51:13 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 19:51:08 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k4CJp3QJ014627; Fri, 12 May 2006 21:51:03 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k4CJp3f1013721; Fri, 12 May 2006 21:51:03 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k4CJp1ao000358; Fri, 12 May 2006 21:51:02 +0200 (CEST) Date: Fri, 12 May 2006 19:57:00 -0000 Message-Id: <200605121951.k4CJp1ao000358@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: fnf@specifix.com CC: gdb-patches@sourceware.org, fnf@specifix.com In-reply-to: <200605101424.11088.fnf@specifix.com> (message from Fred Fish on Wed, 10 May 2006 14:24:10 -0400) Subject: Re: [RFC] DWARF 2 address size != pointer size References: <200605101424.11088.fnf@specifix.com> 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/msg00259.txt.bz2 > From: Fred Fish > Date: Wed, 10 May 2006 14:24:10 -0400 > > For at least one target, MIPS using the o64 ABI with -mlong64, the > target DWARF2 address size used in the DWARF info (32 bit) is not the > same as the target pointer size (64 bit). Unbelievable. As if there aren't enough ABI's for MIPS yet. But how can this work? If the pointers are really 64-bit, how can they be encoded in the 32-bit DWARF2 adresses? > For example, below are some fragments from dumping the DWARF info > for a simple test case: > > Compilation Unit @ 0: > Length: 175 > Version: 2 > Abbrev Offset: 0 > Pointer Size: 4 > <1><91>: Abbrev Number: 3 (DW_TAG_base_type) > DW_AT_name : long int > DW_AT_byte_size : 8 > <1>: Abbrev Number: 4 (DW_TAG_pointer_type) > DW_AT_byte_size : 8 > > Note that the header records the address size as 4, which is the > number of bytes written to the DWARF info when writing addresses, but > that the target pointer size is 8. > > Currently gdb computes the DWARF info address size as: > > TARGET_ADDR_BIT / TARGET_CHAR_BIT > > Given that the address size is actually recorded in the compilation > unit header, I believe the best solution would be to use that recorded > value somehow. I spent a couple days looking for an easy way to tie > the address size to DWARF expressions that were recorded for later > evaluation, but didn't come up with anything clean enough to submit. > > Another way to divorce the DWARF address size from the TARGET_ADDR_BIT > is to add another gdbarch paramter, accessed as TARGET_DWARF_ADDR_BIT. > I've attached a patch that does that. It's simple, but not my first > choice for solving the problem. > > Comments? I think introducing TARGET_DWARF_ADDR_BIT is a mistake if the debug info already encodes the info.