This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: handle cached local static DIEs


Hi Jason.

After my last set of dwarf changes for locals, I found some target library building failures which I am now fixing.

The problem at hand is that, by design, the caching code in gen_variable_die() refuses to use a previously cached DIE if the current context and the cached context are different:

       else if (old_die->die_parent != context_die)
        {
          /* If the contexts differ, it means we're not talking about
             the same thing.  Clear things so we can get a new DIE.
             This can happen when creating an inlined instance, in
             which case we need to create a new DIE that will get
             annotated with DW_AT_abstract_origin.  */
          old_die = NULL;
          gcc_assert (!DECL_ABSTRACT_P (decl));
        }

This is causing problems with local statics which are handled at dwarf2out_late_global_decl, and which originally have a context of the compilation unit (by virtue of the dwarf2out_decl call). This context then gets changed here:

      /* For local statics lookup proper context die.  */
      if (TREE_STATIC (decl)
	  && DECL_CONTEXT (decl)
	  && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL)
	context_die = lookup_decl_die (DECL_CONTEXT (decl));

This new context may be correct for front/middle-end purposes, but is not the DIE context I am expecting in gen_variable_die. For example, in the following example, the DECL_CONTEXT for the static is funky's DW_TAG_subprogram, whereas the caching code is expecting the DW_TAG_lexical_block:

	void funky()
	{
	  {
	    static const char *nested_static_const = "testing123";
	  }
	}

My proposed way of handling it (attached) is by tightening the check in gen_variable_die(), and special casing this scenario (assuming, there is no other way to get a differing context). This works, and fixes all the failures, without introducing any regressions.

Another approach would be to use whatever context is already cached with just "context_die = lookup_decl_die (decl)", but that feels like cheating.

Are you OK with the attached approach, or do you have something else in mind?

Thanks.
Aldy

Attachment: curr
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]