From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17536 invoked by alias); 23 Jan 2004 22:28:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17523 invoked from network); 23 Jan 2004 22:28:25 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 23 Jan 2004 22:28:25 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 7727B1A440D; Fri, 23 Jan 2004 17:26:03 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16401.40827.389460.389150@localhost.redhat.com> Date: Fri, 23 Jan 2004 22:28:00 -0000 To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy , Daniel Jacobowitz , Michael Elizabeth Chastain Subject: Re: [rfa] set processing_current_prefix properly (PR gdb/1520) In-Reply-To: References: X-SW-Source: 2004-01/txt/msg00635.txt.bz2 David Carlton writes: > This is a fix for PR gdb/1520, a namespace problem with GCC 3.4. The > problem was that, if we have this situation: > > namespace N { > void foo() { } > } > > then the compiler I had been using generated dies as following in its > DWARF 2 output: > > 1: DW_TAG_namespace: > > 2: DW_TAG_subprogram: > > // Definition of N::foo > > whereas GCC head does: > > 1: DW_TAG_namespace: > > 2: DW_TAG_subprogram: > > // Declaration for N::foo > > 3: DW_TAG_subprogram: > > DW_AT_specification: reference to die #2 > > // Definition of N::foo. > > > So I've added code to notice if a die representing a function's > definition has a specification located elsewhere; if so, it looks at > that specification to discover the current enclosing class/namespace. > Can you add some of the above comments before the new call to check for the specification? > (Probably there are other places where we need to do this; hopefully, > after a bit more experience, we'll find a less ad-hoc way of handling > this issue.) > > It also fixes an inconsistency in my last patch - I had tried to > maintain the invariant that processing_current_prefix was always > non-NULL (i.e. was an actual string, albeit possibly an empty one), > but I was using determine_prefix in ways that violated that invariant. > So the only function that one should call in theory should be determine_prefix, while possibly_determine_prefix is only there as a worker function? Maybe this should be reflected in the names a bit more explicitly. Like determine_prefix_worker or something like that for the 'internal' one. I cannot think of a better term right now. > Tested on i686-pc-linux-gnu, DWARF 2, with GCC 3.2, GCC 3.2 + > DW_TAG_namespace patch, GCC 2.95.3, and GCC head. No regressions; > fixes lots of FAILs in gdb.cp/namespace.exp with GCC head. (From now > on, I'll probably stop testing with my patched GCC 3.2 and switch to > using a GCC snapshot generating DW_TAG_namespace, so I don't miss > problems like this.) > > Okay to commit? > ok, modulus those 2 nits. elena