public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: gcc-patches@gcc.gnu.org, jason@redhat.com
Subject: Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug
Date: Thu, 20 Aug 2015 10:25:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1508201211590.4884@zhemvz.fhfr.qr> (raw)
In-Reply-To: <alpine.LSU.2.11.1508191531490.19998@zhemvz.fhfr.qr>

On Wed, 19 Aug 2015, Richard Biener wrote:

> On Tue, 18 Aug 2015, Aldy Hernandez wrote:
> 
> > On 08/18/2015 07:20 AM, Richard Biener wrote:
> > > 
> > > This starts a series of patches (still in development) to refactor
> > > dwarf2out.c to better cope with early debug (and LTO debug).
> > 
> > Awesome!  Thanks.
> > 
> > > Aldyh, what other testing did you usually do for changes?  Run
> > > the gdb testsuite against the new compiler?  Anything else?
> > 
> > gdb testsuite, and make sure you test GCC with --enable-languages=all,go,ada,
> > though the latter is mostly useful while you iron out bugs initially.  I found
> > that ultimately, the best test was C++.
> 
> I see.
> 
> > Pre merge I also bootstrapped the compiler and compared .debug* section sizes
> > in object files to make sure things were within reason.
> > 
> > > +
> > > +static void
> > > +vmsdbgout_early_finish (const char *filename ATTRIBUTE_UNUSED)
> > > +{
> > > +  if (write_symbols == VMS_AND_DWARF2_DEBUG)
> > > +    (*dwarf2_debug_hooks.early_finish) (filename);
> > > +}
> > 
> > You can get rid of ATTRIBUTE_UNUSED now.
> 
> Done.  I've also refrained from moving
> 
>   gen_scheduled_generic_parms_dies ();
>   gen_remaining_tmpl_value_param_die_attribute ();
> 
> for now as that causes regressions I have to investigate.

So I thought gen_scheduled_generic_parms_dies was fine but it exposes
a hole in

  /* Generate early debug for global variables.  Any local variables will
     be handled by either handling reachable functions from
     finalize_compilation_unit (and by consequence, locally scoped
     symbols), or by rest_of_type_compilation below.
...
      && !decl_type_context (decl))
    (*debug_hooks->early_global_decl) (decl);

for __timepunct_cache::_S_timezones where through the
rest_of_type_compilation we quickly finish processing __timepunct_cache
as it is TYPE_DECL_SUPPRESS_DEBUG (so ->type_decl exits w/o doing
anything).  So we fail to generate a type DIE for the global which
causes us, at late_global_decl time (we do output this global var)
ends up doing

#12 0x0000000000b831f1 in gen_decl_die (decl=0x7ffff5650a20, origin=0x0, 
    context_die=0x7ffff62ab000)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:21535
21532         /* And its containing type.  */
21533         class_origin = decl_class_context (decl_or_origin);
21534         if (class_origin != NULL_TREE)
21535           gen_type_die_for_member (class_origin, decl_or_origin, 
context_die);

and thus create the type DIE for __timepunct_cache late.

This is a hole in current early-debug.  IMHO we should force
early_global_decl even for globals in decl_type_context ()
or at least for a type DIE to be created for TYPE_DECL_SUPPRESS_DEBUG
type decls.

Jason, any advice on this?  I note

/* In a TYPE_DECL nonzero means the detail info about this type is not 
dumped
   into stabs.  Instead it will generate cross reference ('x') of names.
   This uses the same flag as DECL_EXTERNAL.  */
#define TYPE_DECL_SUPPRESS_DEBUG(NODE) \
  (TYPE_DECL_CHECK (NODE)->decl_common.decl_flag_1)

refering to STABS and "This uses the same flag as DECL_EXTERNAL" so
maybe this is just bad co-incidence?  DECL_EXTERNAL doesn't check
it operates on a non-TYPE_DECL.

So without knowing that the flag is supposed to be doing in DWARF
(also the desired effect on any of its static members) I can only
suggest we maybe do not want any debug info for 
__timepunct_cache::_S_timezones at all?

Thanks,
Richard.

  parent reply	other threads:[~2015-08-20 10:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 14:42 Richard Biener
2015-08-18 19:48 ` Aldy Hernandez
2015-08-19  9:36   ` Yao Qi
2015-08-19 13:55   ` Richard Biener
2015-08-19 13:57     ` Aldy Hernandez
2015-08-19 14:54       ` Pedro Alves
2015-08-20  9:31     ` Richard Biener
2015-08-20 10:25     ` Richard Biener [this message]
2015-08-20 10:32       ` Richard Biener
2015-08-21 13:46         ` Richard Biener
2015-08-26 10:50     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.11.1508201211590.4884@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).