From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10137 invoked by alias); 15 Mar 2010 20:00:27 -0000 Received: (qmail 10126 invoked by uid 22791); 15 Mar 2010 20:00:26 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_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, 15 Mar 2010 20:00:17 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2FK0Elu006724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Mar 2010 16:00:15 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2FK0DGP002826; Mon, 15 Mar 2010 16:00:13 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o2FK0C3Y020287; Mon, 15 Mar 2010 16:00:13 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8062B378261; Mon, 15 Mar 2010 14:00:11 -0600 (MDT) From: Tom Tromey To: gdb-patches@sourceware.org Subject: Re: FYI: fix PR 9708 References: <20100313023630.GA29285@caradoc.them.org> Reply-To: Tom Tromey Date: Mon, 15 Mar 2010 20:00:00 -0000 In-Reply-To: <20100313023630.GA29285@caradoc.them.org> (Daniel Jacobowitz's message of "Fri, 12 Mar 2010 21:36:34 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-03/txt/msg00558.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: [...] Daniel> Now one of those is going to get a namespace and the other isn't. Daniel> I'd have thought we would call them both f()::x - although clearly Daniel> that's not sufficient to uniquely identify them. Should they Daniel> both be ! die_needs_namespace? Yes, I think we should also omit DW_TAG_subprogram here. I just didn't think of it. I can either just check it in, or if you have an easy way to test it, let me know. I've appended the patch. Calling them f()::x might be interesting, but there are some caveats. First, I am not sure the rest of gdb (I'm thinking the parser at least) is set up to handle this. AFAIK this would be a new feature. Second, we'd probably have to insert two symbols here -- one for the global name and one for the local name. There are cases where gcc has to give the static a synthetic linkage name, e.g.: struct K { int m () { static bool themagicstatic = false; int x; { static bool themagicstatic = false; x = themagicstatic ? 23 : 24; } return x + themagicstatic ? 23 : 24; } } This leads to: opsy. nm pr | grep themagicstatic 080497de V _ZZN1K1mEvE14themagicstatic 080497dd V _ZZN1K1mEvE14themagicstatic_0 .. so in the inner scope, we still need a symbol named "themagicstatic"; calling it "themagicstatic_0" would be confusing to the user. Daniel> I'm sure I originally fixed some bug by giving these things the Daniel> physname of 'x'... but probably, whatever it was is also fixed by your Daniel> change to use list_in_scope. Yeah, the die_needs_namespace change is needed to get the proper name for the symbol in new_symbol. Otherwise it ends up like "K::themagicstatic", which is wrong. Tom *** dwarf2read.c.~1.366.~ 2010-03-12 17:20:15.000000000 -0700 --- dwarf2read.c 2010-03-15 13:47:54.000000000 -0600 *************** *** 3241,3247 **** and have a mangled name. */ if (die->parent->tag == DW_TAG_lexical_block || die->parent->tag == DW_TAG_try_block ! || die->parent->tag == DW_TAG_catch_block) return 0; return 1; --- 3241,3248 ---- and have a mangled name. */ if (die->parent->tag == DW_TAG_lexical_block || die->parent->tag == DW_TAG_try_block ! || die->parent->tag == DW_TAG_catch_block ! || die->parent->tag == DW_TAG_subprogram) return 0; return 1;