From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21138 invoked by alias); 12 Jun 2003 22:26:35 -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 21079 invoked from network); 12 Jun 2003 22:26:32 -0000 Received: from unknown (HELO dhcp-10-42-69-238.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 12 Jun 2003 22:26:32 -0000 Received: from dhcp-10-42-69-238.kealia.com (coconut.kealia.com [127.0.0.1]) by dhcp-10-42-69-238.kealia.com (8.12.8/8.12.8) with ESMTP id h5CMQYks005869; Thu, 12 Jun 2003 15:26:34 -0700 Received: (from carlton@localhost) by dhcp-10-42-69-238.kealia.com (8.12.8/8.12.8/Submit) id h5CMQYDZ005867; Thu, 12 Jun 2003 15:26:34 -0700 X-Authentication-Warning: dhcp-10-42-69-238.kealia.com: carlton set sender to carlton@kealia.com using -f To: gdb-patches@sources.redhat.com Cc: Daniel Jacobowitz Subject: [rfa] always use demangled name to set scope From: David Carlton Date: Thu, 12 Jun 2003 22:26:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00434.txt.bz2 As per recent discussions, it seems likely that the variable 'processing_current_namespace' isn't always valid: if a function is declared in a namespace but defined outside the body of that namespace, then probably sometimes dwarf2read.c won't notice that, because of a DW_AT_specification tag, the current namespace is different from what is given by the immediate hierarchical structure. I'm trying to sort this out on my branch, but I think I'd prefer a less intrusive fix on the mainline, since we're about to branch for GDB 6.0. Fortunately, the mainline currently only uses that variable in once place, namely cp_set_block_scope. And, in that situation, it has the fallback strategy of looking at the demangled name. So this patch tells GDB to just always use that fallback strategy for now. It should work fine in the short term; we can get this all straightened out fully for 6.1, as part of merging in the rest of my branch (in particular nested types support). Tested on GCC 3.2, DWARF 2, i686-pc-linux-gnu; no new regressions. I also ran gdb.c++/namespace.exp with a version of GCC patched to generated DW_TAG_namespace entries, and I didn't get any regressions there, either. OK to commit? David Carlton carlton@kealia.com 2003-06-12 David Carlton * cp-namespace.c (cp_set_block_scope): Comment out processing_has_namespace_info branch. Index: cp-namespace.c =================================================================== RCS file: /cvs/src/src/gdb/cp-namespace.c,v retrieving revision 1.2 diff -u -p -r1.2 cp-namespace.c --- cp-namespace.c 20 May 2003 03:56:28 -0000 1.2 +++ cp-namespace.c 12 Jun 2003 22:17:47 -0000 @@ -38,6 +38,9 @@ unsigned char processing_has_namespace_i contain the name of the current namespace. The string is temporary; copy it if you need it. */ +/* FIXME: carlton/2003-06-12: This isn't entirely reliable: currently, + we get mislead by DW_AT_specification. */ + const char *processing_current_namespace; /* List of using directives that are active in the current file. */ @@ -187,6 +190,12 @@ cp_set_block_scope (const struct symbol if (SYMBOL_CPLUS_DEMANGLED_NAME (symbol) != NULL) { +#if 0 + /* FIXME: carlton/2003-06-12: As mentioned above, + 'processing_has_namespace_info' currently isn't entirely + reliable, so let's always use demangled names to get this + information for now. */ + if (processing_has_namespace_info) { block_set_scope @@ -196,6 +205,7 @@ cp_set_block_scope (const struct symbol obstack); } else +#endif { /* Try to figure out the appropriate namespace from the demangled name. */