public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Richard Biener <rguenther@suse.de>, gcc-patches@gcc.gnu.org
Subject: Re: [PING][PATCH][2/2] Early LTO debug -- main part
Date: Tue, 22 Nov 2016 22:50:00 -0000	[thread overview]
Message-ID: <5e42756e-8064-3a9e-9ffb-5693169097aa@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1611110859520.5294@t29.fhfr.qr>

On 11/11/2016 03:06 AM, Richard Biener wrote:
> +    /* ???  In some cases the C++ FE (at least) fails to
> +       set DECL_CONTEXT properly.  Simply globalize stuff
> +       in this case.  For example
> +       __dso_handle created via iostream line 74 col 25.  */

The comment for DECL_CONTEXT says that a VAR_DECL can have 'NULL_TREE or 
a TRANSLATION_UNIT_DECL if the given decl has "file scope"'

So this doesn't seem like a FE bug.

> +		  /* ???  We cannot unconditionally output die_offset if
> +		     non-zero - at least -feliminate-dwarf2-dups will
> +		     create references to those DIEs via symbols.  And we
> +		     do not clear its DIE offset after outputting it
> +		     (and the label refers to the actual DIEs, not the
> +		     DWARF CU unit header which is when using label + offset
> +		     would be the correct thing to do).

I'd be happy to remove or disable -feliminate-dwarf2-dups at this point, 
since it's already useless for C++ without reimplementation.

> +      /* "Unwrap" the decls DIE which we put in the imported unit context.
> +          ???  If we finish dwarf2out_function_decl refactoring we can
> +	  do this in a better way from the start and only lazily emit
> +	  the early DIE references.  */

Can you elaborate more on the refactoring?  dwarf2out_function_decl is 
already very small, I'm guessing you mean gen_subprogram_die?

> +      /* ???  We can't annotate types late, but for LTO we may not
> +	 generate a location early either (gfortran.dg/save_5.f90).
> +	 The proper way is to handle it like VLAs though it is told
> +	 that DW_AT_string_length does not support this.  */

I think go ahead and handle it like VLAs, this is an obvious 
generalization and should go into the spec soon enough.  This can happen 
later.

> +	  /* ???  This all (and above) should probably be simply
> +	     a ! early_dwarf check somehow.  */
> +	   && ((DECL_ARTIFICIAL (decl) || in_lto_p)
>  	       || (get_AT_file (old_die, DW_AT_decl_file) == file_index
>  		   && (get_AT_unsigned (old_die, DW_AT_decl_line)
>  		       == (unsigned) s.line))))

Why doesn't the existing source position check handle the LTO case? 
Also the extra parens aren't necessary.

>        /* If we're emitting an out-of-line copy of an inline function,
>  	 emit info for the abstract instance and set up to refer to it.  */
> +      /* ???  We have output an abstract instance early already and
> +         could just re-use that.  This is how LTO treats all functions
> +	 for example.  */

Isn't this what you do now?

> +      /* Avoid generating stray type DIEs during late dwarf dumping.
> +         All types have been dumped early.  */
> +      if (! (decl ? lookup_decl_die (decl) : NULL)

Why do you still want to gen_type_die if decl_or_origin is origin?

> +init_sections_and_labels (bool early_lto_debug)

You're changing this function to do the same thing in four slightly 
different ways rather than two.  I'd rather control each piece as 
appropriate; we ought to make SECTION_DEBUG or 
SECTION_DEBUG|SECTION_EXCLUDE a local variable, and select between 
*_SECTION and the DWO variant at each statement rather than in different 
blocks.

> +      /* Remove DW_AT_macro from the early output.  */
> +      if (have_macinfo)
> +	remove_AT (comp_unit_die (),
> +		   dwarf_strict ? DW_AT_macro_info : DW_AT_GNU_macros);

This will need adjustment for Jakub's DWARF 5 work.  Please make the 
choice of AT value a macro.

> +  /* ???  Mostly duplicated from dwarf2out_finish.  */

:(

Jason

  reply	other threads:[~2016-11-22 22:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 11:26 [PATCH][2/2] " Richard Biener
2016-11-11  8:07 ` [PING][PATCH][2/2] " Richard Biener
2016-11-22 22:50   ` Jason Merrill [this message]
2016-11-24 13:50     ` Richard Biener
2016-11-24 14:57       ` Richard Biener
2016-11-28 17:21       ` Jason Merrill
2017-05-19 10:33         ` 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=5e42756e-8064-3a9e-9ffb-5693169097aa@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).