Re: PR22034

[Jan Hubicka <jh at suse dot cz>]

> On Wed, 2005-08-10 at 17:34 -0700, Mark Mitchell wrote:
> > Jan Hubicka wrote:
> > >>Jan Hubicka wrote:
> > >>
> > >>>Hi,
> > >>>The problem is that statics inside classes have TYPEs as contextes.  I 
> > >>>think
> > >>>proper fix is to unwind them up to the containing scope.
> > >>>
> > >>>Bootstrapped/regtested i686-pc-gnu-linux, OK?
> > >>>
> > >>>       /* For local statics lookup proper context die.  */
> > >>>       if (TREE_STATIC (decl) && decl_function_context (decl))
> > >>>! 	{
> > >>>! 	  tree context = DECL_CONTEXT (decl);
> > >>>! 
> > >>>! 	  while (TYPE_P (context))
> > >>>! 	    context = TYPE_CONTEXT (context);
> > >>>! 	  context_die = lookup_decl_die (context);
> > >>>! 	}
> > >>
> > >>Note that you can then end up with a FUNCTION_DECL as the context again. 
> > >> Like:
> > >>
> > >>  void f() {
> > >>   struct S {
> > >>     void g() {
> > >>       struct T {
> > >>         virtual void f();
> > >>       };
> > >>     }
> > >>   }
> > >> }
> > >>
> > >>The virtual table for T will be inside lots of things.
> > >>
> > >>So, don't you need to iterate on both conditions?
> > > 
> > > 
> > > Well, I think that in this case the context I should put f() in is g's
> > > internal scope, but perhaps I am wrong here - dwarf is definitly not my
> > > domain :(
> > > I will try to check this out tomorrow unless someone more aware of the
> > > detials explains it...
> > 
> > If you have that flexibility, why not put it directly in T?  That's 
> > where it really belongs!
> 
> Hmmmmmmmmmmmmmmmmm.
> 
> How do we handle static class variables and functions right now?

I believe that those simply don't have contextes.  Originally the
context was computed while walking the BIND_EXPRs of functions (so all
the variables declared in given BIND_EXPRs got the context).  Thus I
believe I have to walk up to the closest BIND_EXPR (that should be there
for local statics) to immitate the original behaviour independently on
whether it was correct or not...
> We should be able to do the same thing whether the type is local to the
> function or not.
> 
> Jan, in the example you gave, where was the static?

... Hmm ;)
The decl is _ZTVZ19GetAssertStackTracevE9StackDump (vtable for
GetAssertStackTrace()::StackDump) whose context is the class itself.
Why do we emit debug infos for vtables at first place?
I seem to get that probably best thing would be to get the context set
to the type but we don't produce dies for types at all, right?

Honza

> > 
>