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.
next prev 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).