From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14987 invoked by alias); 15 Sep 2009 16:12:13 -0000 Received: (qmail 14898 invoked by uid 22791); 15 Sep 2009 16:12:12 -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; Tue, 15 Sep 2009 16:12:00 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0B00710C48; Tue, 15 Sep 2009 16:11:59 +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 E8829104DF; Tue, 15 Sep 2009 16:11:58 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MnadK-0008U3-2J; Tue, 15 Sep 2009 12:11:58 -0400 Date: Tue, 15 Sep 2009 16:12:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname Message-ID: <20090915161158.GA31410@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org References: <4A9C54F6.1000909@eagercon.com> <4A9C5A66.7060609@redhat.com> <20090901221122.GA24658@caradoc.them.org> <4A9DADB6.2090508@redhat.com> <20090901234212.GB32355@caradoc.them.org> <4AAE8DDB.3060005@redhat.com> <20090914224754.GA7012@caradoc.them.org> <4AAED830.5080909@redhat.com> <20090915133207.GA17606@caradoc.them.org> <4AAFB868.9050407@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAFB868.9050407@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-09/txt/msg00486.txt.bz2 On Tue, Sep 15, 2009 at 08:53:12AM -0700, Keith Seitz wrote: > I played with this a bit, and it seems that only ctors and dtors have > DIEs outside the class definition (ignoring "normal" C functions). > However, in every case I tried, ICC does not output DW_AT_artificial > for ANY class method's first parameter. Does ICC not use hidden > parameter passing to implement method calls? It seems odd that it > would do this for ctors/dtors and no other methods. >From the standard: === If the member function entry describes a non-static member function, then that entry has a DW_AT_object_pointer attribute whose value is a reference to the formal parameter entry that corresponds to the object for which the function is called. The name attribute of that formal parameter is defined by the current language (for example, this for C++ or self for Objective-C and some other languages). That parameter also has a DW_AT_artificial attribute whose value is true. Conversely, if the member function entry describes a static member function, the entry does not have a DW_AT_object_pointer attribute. === So, if icc is failing to mark things artificial, does it make up for it by having DW_AT_object_pointer? I don't believe GCC generates that attribtue (guess it should!). > It may just be useful to provide (yet another) switch to turn on > DW_AT_MIPS_linkage_name processing (and disable the proposed physname > work). We could do this switch manually (set dwarf-linkage-name on?) > and/or by producer (turn it on for ICC by default). This is an area where, pain or not, I'd really prefer to have only one way to do things. I looked over your patch again. I have no objection and Tom's already approved it upthread; I think you're good to go. -- Daniel Jacobowitz CodeSourcery