From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28825 invoked by alias); 14 Sep 2009 22:48:04 -0000 Received: (qmail 28798 invoked by uid 22791); 14 Sep 2009 22:48:02 -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; Mon, 14 Sep 2009 22:47:57 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 44ED310705; Mon, 14 Sep 2009 22:47:55 +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 1AAF11065D; Mon, 14 Sep 2009 22:47:55 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MnKKw-00027x-EL; Mon, 14 Sep 2009 18:47:54 -0400 Date: Mon, 14 Sep 2009 22:48:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname Message-ID: <20090914224754.GA7012@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org 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> <4AAE8DDB.3060005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAE8DDB.3060005@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/msg00464.txt.bz2 On Mon, Sep 14, 2009 at 11:39:23AM -0700, Keith Seitz wrote: > 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. Hi Keith, I'm really sorry about the rathole. I expected you'd just ask me to do it... you're correct that you are going to get a lot of failures with RealView. I have patches for some of the worst, both in testsuite patterns and in GDB proper. Part of the reason I haven't posted them yet, though, is this exact issue - one of the patches in our tree for RealView support is the stone-age ancestor of your patches :-) ICC, though, I'm pretty surprised; we get bug reports about people using ICC once in a while, and I thought someone had tested it... Now that you've gone to the trouble, though, let's make the most of your work. Could I persuade you to put the wrappers you needed and where to get appropriate compilers onto the GDB wiki? > 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.] This is excellent news. Some things will blow up in new and exciting ways when we start relying on the template arguments emitted by the compiler; they're incomplete for some of the nasty examples I tried. But if we can debug normal-ish templates, we've made great progress. > <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) > <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. Ouch. Though, why does this make life difficult for the debugger? The problem of THIS not being artificial I've seen before - I think RealView has the same problem; I may have a patch to work around it - but I'm not sure why we care about the name of the parameter in the declaration. > Is there anything else you want me to investigate? No, I'm happy. Is this patch still current? If so, I'll review it tonight. -- Daniel Jacobowitz CodeSourcery