[rfc/rfa] accept DW_TAG_namespace and friends, possibly on 5.3

[Andrew Cagney]

> On Tue, Oct 22, 2002 at 01:40:25PM -0700, 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'd like to raise my voice in support of this patch, for both trunk and
> 5.3-branch.  David's quite right - we need this in order for GCC to
> move forward, in order for us to move forward.

Me to, now we're talking :-) One less lame excuse for a GCC developer to 
beat us up :-)

Andrew