Re: [rfa] lookup_transparent_type hack

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jan 16, 2004 at 03:58:04PM -0800, David Carlton wrote:
> This is a hack for lookup_transparent_type, as a partial workaround
> for PR gdb/1511.  The problem there is, if the compiler doesn't
> generate DW_TAG_namespace, then, if we have a class C defined inside a
> namespace N, then when GDB sees an abstract declaration for N::C, it
> will think it's called "C" instead of "N::C".  Then
> lookup_transparent_type will get passed "C", and it won't find the
> full definition for the class (which is called "N::C").
> 
> I don't see what we can do about this without full debugging info -
> GDB can't very well look in all the namespaces out there.  One

Well, we can.  I'm thinking about sorting the symbol tables by
basename, as I mentioned earlier.  That would make this search easy. 
But the only cases where it would be really interesting, it would still
be ambiguous...

> heuristic which has proved useful, however, is to try looking in the
> namespaces associated to the function we're currently within (if any),
> on the theory that we're a bit more likely to be dealing with types in
> those namespaces than types in other namespaces.  It's a hack, but it
> does seem to help.
> 
> Here's a patch to do that.  It needs C++ approval, and it would be
> nice if a symtab person would confirm that it's okay to make
> lookup_transparent_type language-dependent.  Tested on
> i686-pc-linux-gnu, DWARF-2, GCC 3.2 both with and without
> DW_AT_namespace; no regressions, and the new test passes in both
> cases.  (It shouldn't affect stabs, though I'm running the testsuite
> now just to double-check.)
> 
> Okay to commit?

This is OK.  I'd also like to see results with 2.95, though I expect no
difficulties.  It's a terrible hack, but you're right that it probably
works often enough to bother.

It doesn't work for the case that has been reported twice now:
namespace bar {
  class Foo { };
  namespace baz {
    class Foo : public bar::Foo { };
  }
}

There's nothing clear we can do, although bonus points would definitely
be had for making sure we don't resolve the derived type's reference
to the base type to the derived type itself.  Again, a hack, won't
catch larger cycles, but would eliminate some infinite loops.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer