From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1790 invoked by alias); 22 Oct 2002 21:17:52 -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 1779 invoked from network); 22 Oct 2002 21:17:51 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 22 Oct 2002 21:17:51 -0000 Received: from dberlin.org (pool-138-88-93-214.res.east.verizon.net [138.88.93.214]) by mail.cdt.org (Postfix) with ESMTP id 4FF2F4900C4; Tue, 22 Oct 2002 16:52:32 -0400 (EDT) Received: from [192.168.0.1] (HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 1070936; Tue, 22 Oct 2002 17:17:49 -0400 Date: Tue, 22 Oct 2002 14:17:00 -0000 From: Daniel Berlin To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy Subject: Re: [rfc/rfa] accept DW_TAG_namespace and friends, possibly on 5.3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00425.txt.bz2 On 22 Oct 2002, David Carlton wrote: > The current situation around C++ namespace debugging info is that GCC > isn't generating it because, if it were generating it, it would > produce debugging info that GDB really can't handle. Basically, > DW_TAG_namespace entries have children that are important, so GDB has > to know a little bit about those nodes in order not to miss large > chunks of debugging info. (This is true whether or not GDB wants to > do anything particularly namespace-specific with that debugging info.) > > So it seems to me like it would be a good idea to change GDB as > quickly as possible to not get confused by DW_TAG_namespace (as well > as DW_TAG_imported_declaration and DW_TAG_imported_module): we > shouldn't wait until adding more namespace functionality to GDB. For > example, if that support makes it into GDB 5.3, then maybe GCC 3.3 > will be able to generate the appropriate debugging info, so when a GDB > 5.4 (or whatever) rolls around that handles namespaces better, users > will be able to take advantage of it immediately (instead of having to > wait for the next GCC release). > > Here are some patches to let GDB accept that debugging information: I > think it would be a good idea to get it into 5.3 as well as mainline, > if possible. They're quite minimal changes: they make sure that, when > reading partial symbols, we descend into DW_TAG_namespace entries, > that when reading full symbols, we read children of DW_TAG_namespace > entries (but we don't keep around any more namespace information than > we do currently: e.g. we still get names from > DW_AT_MIPS_linkage_name), and that we don't complain about the > presence of DW_TAG_imported_declaration or DW_TAG_imported_module (but > we also don't do anything useful about that info). > > I've tested this using current GCC, using GCC as patched according to > , and using > GCC as patched according to that message plus the following patch: > > --- dwarf2out.c-danielb Fri Oct 18 11:39:46 2002 > +++ dwarf2out.c Fri Oct 18 11:38:46 2002 > @@ -11453,7 +11453,11 @@ gen_namespace_die (decl, context_die) > { > /* Output a real namespace */ > dw_die_ref namespace_die = new_die (DW_TAG_namespace, context_die, decl); > - add_name_and_src_coords_attributes (namespace_die, decl); > + /* Anonymous namespaces shouldn't have a DW_AT_name. */ > + if (strncmp (dwarf2_name (decl, 0), "_GLOBAL__N", 10) == 0) > + add_src_coords_attributes (namespace_die, decl); > + else > + add_name_and_src_coords_attributes (namespace_die, decl); > equate_decl_number_to_die (decl, namespace_die); > } > else Just FYI, the real fix is to move anonymous_namespace_name from cp/cp-tree.h to c-common.h, and the actual declaration from cp/decl.c to c-common.c , and pointer compare DECL_NAME (decl) to anonymous_namespace_name. > > In all cases, there are no new regressions. Unfortunately, I don't > currently have a version of GCC that emits many > DW_TAG_imported_declarations or any DW_TAG_imported_modules; I hope > that I'll have one soon (Daniel Berlin is working on it but he's busy; > maybe I'll try to work on it myself, too), I should have it done in a few hours, actually.