From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21217 invoked by alias); 14 Sep 2009 18:39:35 -0000 Received: (qmail 21181 invoked by uid 22791); 14 Sep 2009 18:39:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 18:39:28 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8EIdR5F022744 for ; Mon, 14 Sep 2009 14:39:27 -0400 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8EIdN07001814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Sep 2009 14:39:26 -0400 Message-ID: <4AAE8DDB.3060005@redhat.com> Date: Mon, 14 Sep 2009 18:39:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname References: <4A9C358E.2050904@redhat.com> <4A9C54F6.1000909@eagercon.com> <4A9C5A66.7060609@redhat.com> <20090901221122.GA24658@caradoc.them.org> <4A9DADB6.2090508@redhat.com> <20090901234212.GB32355@caradoc.them.org> In-Reply-To: <20090901234212.GB32355@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00436.txt.bz2 On 09/01/2009 04:42 PM, Daniel Jacobowitz wrote: > OK. That'd be a big improvement over the last state of my tree; in > order to call a memeber function, we had to match the ELF symbol > exactly or GDB would bogusly report it as "inlined". A lot has changed since the patch you sent me. I'd be surprised if you even recognized your patch inside mine. :-) > If uniqueness is all that's required, maybe there's some less > expensive representation than a string encoding of the arguments? That makes searching for a symbol a lot more difficult and slower. The point of this is to reduce all classes/templates/methods/etc names to their most basic source code representations to make searching easier and more reliable. The sad fact of the matter is, linkage_names are NOT reliable. > I'm happy to test with RealView. I might be able to test with ICC > also, but I haven't tried that in forever. I believe it's freely > available. I've spent the last 1.5 weeks investigating proprietary compilers, and I can only assume that no one seriously ever runs gdb's test suite on either RealView or ICC. CVS HEAD shows almost 1,000 test failures on each compiler. I could not even get dejagnu to cope with non-gcc compilers without resorting to writing wrappers around ICC and RealView to translate gcc command-line options into something appropriate for those other proprietary compilers. But here's what I've discovered. ARM RealView: My expr-cumulative branch introduces three regression failures -- two of them in C++ tests. However, it also allows RealView to pass over two hundred previously failing or erroring C++ tests. I can provide diffs. On my "realcpp" test, RealView fails almost all of the template tests. This is because RealView relies on DW_AT_template_* attributes which gdb does not yet know about. [This will likely be my next task.] ICC: This compiler really relies on DW_AT_MIPS_linkage_name because its DWARF output is *seriously* messed up. As expected on expr-cumulative, ICC fails approximately 60 additional C++ tests. The main problem is not that it doesn't really pass the test, but because of ICC's foobar'd DWARF output, the user has to do things a little differently, e.g., "break foo::foo" doesn't work, but "break foo::foo()" does. As I mentioned, this is because ICC plays fast and loose with the DWARF standard. Take, for example, the simple case of a constructor, foo::foo(void), ICC will output (this is the first DIE after the comp unit DIE): <1>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_decl_line : 4 DW_AT_decl_column : 3 DW_AT_decl_file : 1 DW_AT_specification: <0x11a> DW_AT_name : foo DW_AT_MIPS_linkage_name: _ZN3fooC1Ev DW_AT_low_pc : 0x8048434 DW_AT_high_pc : 0x804843a <100> DW_AT_external : 1 <2><101>: Abbrev Number: 4 (DW_TAG_formal_parameter) <102> DW_AT_type : <0x147> <106> DW_AT_artificial : 1 <107> DW_AT_name : this <10c> DW_AT_location : 2 byte block: 75 8 (DW_OP_breg5: 8) So far so good. However, if you look at the actual definition of the class foo (<11a>, the specification listed in the DIE above): <1><110>: Abbrev Number: 5 (DW_TAG_class_type) <111> DW_AT_decl_line : 1 <112> DW_AT_decl_column : 7 <113> DW_AT_decl_file : 1 <114> DW_AT_accessibility: 1 (public) <115> DW_AT_byte_size : 1 <116> DW_AT_name : foo <2><11a>: Abbrev Number: 6 (DW_TAG_subprogram) <11b> DW_AT_decl_line : 4 <11c> DW_AT_decl_column : 3 <11d> DW_AT_decl_file : 1 <11e> DW_AT_accessibility: 1 (public) <11f> DW_AT_type : <0x13f> <123> DW_AT_prototyped : 1 <124> DW_AT_name : foo <128> DW_AT_MIPS_linkage_name: _ZN3fooC1Ev <3><134>: Abbrev Number: 7 (DW_TAG_formal_parameter) <135> DW_AT_type : <0x147> <139> DW_AT_name : $01 Here you can see that DIE <134> is NOT marked artificial. Additionally, its DW_AT_name conflicts with the one previously listed, which I think is playing pretty loose with the standard (and certainly makes life difficult for the debugger). I did not even bother with my realcpp tests on this compiler. >> I know that "f<(char*)(&Foo)>" is ugly, but that is the name that gcc >> gives us (DW_AT_name for this DIE), so we have to use it. [I am >> assuming we could get this cleaned up/"fixed" in gcc.] > We could, as long as we do something not horribly nonsensical with the > names there now - which are a bit random. Dodji is already working on this and a bunch of other DWARF cleanups/additions, especially in the area of template debug info. AFAICT his interpretation of the DWARF spec reads more like mine (and ARM's) than Intel's. O:-) Is there anything else you want me to investigate? [PLEASE don't say another proprietary compiler!!] Keith