From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13695 invoked by alias); 24 Nov 2009 22:11:50 -0000 Received: (qmail 13502 invoked by uid 22791); 24 Nov 2009 22:11: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 rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 22:11:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1554B2BAC0A; Tue, 24 Nov 2009 17:11:40 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7nAW+YOP2WPt; Tue, 24 Nov 2009 17:11:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9C8502BAC0C; Tue, 24 Nov 2009 17:11:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4E445F5905; Tue, 24 Nov 2009 17:11:36 -0500 (EST) Date: Tue, 24 Nov 2009 22:11:00 -0000 From: Joel Brobecker To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname Message-ID: <20091124221136.GC26004@adacore.com> References: <4B0707E7.5010308@uglyboxes.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0707E7.5010308@uglyboxes.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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-11/txt/msg00536.txt.bz2 > (read_partial_die): Ignore DW_AT_MIPS_linkage_name for all > languages except Ada. More info on this. After asking the compiler guys, it turns out that GCC generates DIEs with a DW_AT_MIPS_linkage_name attribute when an entity has a different linkage name from the mangled name (this happens when a pragma Export is used to force the linkage name of an entity). For instance: package P is Myconst : Integer := 1234; pragma Export (C, Myconst, "hello"); end P; The compiler generates: .uleb128 0x2 # (DIE (0x25) DW_TAG_variable) .long .LASF3 # DW_AT_name: "p__myconst" .byte 0x1 # DW_AT_decl_file (p.ads) .byte 0x3 # DW_AT_decl_line .long .LASF4 # DW_AT_MIPS_linkage_name: "hello" Now that I have been reminded of this, I now remember that we have an open enhancement request to be able to use either the natural name or the linkage name in order to specify our entity. In other words, users want to be able to do either of: (gdb) print p.myconst (gdb) print hello Right now, we only allow the latter. Honestly, I strongly suspect that this is accidental due to use prefering the DW_AT_MIPS_linkage_name attribute over the DW_AT_name, but ``I wasn't there''. Going back to the enhancement request, the way we were hoping to be able to deal with that was to take advantage of the two names being provided for our DIE, so we can't really think of removing the handling of this attribute entirely without thinking about a different approach first. The approach taken here of conditionalizing this to the CU language against Ada is fine as far as I am concerned - I'll concede that it's a little ugly. In terms of how I'm planning to implement the enhancement, I actually haven't thought much about it. If Ada was able to store both natural and linkage name at the same time (instead of computing the natural name on-demand), it'd probably be working to just compute the natural name based on the DW_AT_name attribute while using the DW_AT_MIPS_linkage_name for the linkage name... I would like Ada to do the same as other projects, but it's not necessarily straightforward. In order to spend the memory to store the natural name, I need to save some memory elsewhere (some of our customers have projects that cause GDB to use up as much memory as allowed by the system!). Tom's work might allow us that saving, but I need to find the time to investigate this first, although one of these customers is on a stabs platform, so it might not help us there... To be continued... -- Joel