public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Pierre-Marie de Rodat <derodat@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][PR debug/65549] Restore DW_AT_abstract_origin for cross-unit call sites
Date: Wed, 10 Jun 2015 07:06:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1506100855090.30088@zhemvz.fhfr.qr> (raw)
In-Reply-To: <55775CDE.2060101@adacore.com>

On Tue, 9 Jun 2015, Pierre-Marie de Rodat wrote:

> Hello,
> 
> With the recent work for PR debug/65549, we observed a regression in the
> generated debugging information. Take the attached reproducer, build it and
> look at the output DWARF:
> 
>      $ gcc -c -O1 -g foo.c
>      $ objdump --dwarf=info foo.o
>      [...]
>       <2><4e>: Abbrev Number: 3 (DW_TAG_GNU_call_site)
>          <4f>   DW_AT_low_pc      : 0x9
>       <2><57>: Abbrev Number: 0
> 
> There is no DW_AT_abstract_origin attribute anymore, whereas there used to be
> one.
> 
> On PowerPC with -mlongcall, for instance, call instructions are indirect and
> we (at AdaCore) rely on this attribute to determine what function is actually
> called (it's easier this way than interpreting machine code...). The DWARF
> proposal for call sites also say debuggers should be able to use this
> attribute (to build virtual call stacks in the presence of tail calls), but I
> could not observe this in practice with GDB.
> 
> The attached patch is an attempt to restore this attribute. The logic behind
> it is: this is what we used to do previously for contexts that are alien
> translation unit (through the call to force_decl_die), so this should not
> harm.
> 
> Bootstrapped and regtested on x86_64-linux. Ok to commit?

Hmm, so the underlying issue is that we don't associate comp_unit_die ()
with any TRANSLATION_UNIT_DECL.  For the LTO early debug work I did
the following at the very beginning of dwarf2out_early_finish:

  /* Pick the first TRANSLATION_UNIT_DECL we didn't create a DIE for
     and equate it with our default CU DIE.  LTO output needs to be
     able to lookup DIEs for translation unit decls.  */
  unsigned i;
  tree decl;
  FOR_EACH_VEC_SAFE_ELT (all_translation_units, i, decl)
    if (!lookup_decl_die (decl))
      equate_decl_number_to_die (decl, comp_unit_die ());

We create some DIEs for builtin types too early before frontends
got a chance to build their TRANSLATION_UNIT_DECL, so comp_unit_die
gets created before there is any TRANSLATION_UNIT_DECL.  Another
approach would of course be that the Frontends register their main
TRANSLATION_UNIT_DECL with dwarf2out via a debug hook.

But - does the above work for you and fix the regression?  If so
adding a debug hook would probably be the cleaner solution still.

Thanks,
Richard.

> Thank you in advance!
> 
> gcc/ChangeLog
>         * dwarf2out.c (lookup_context_die): Return the DIE for the
>         current compilation unit when the input context is a
>         TRANSLATION_UNIT_DECL.
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)

  reply	other threads:[~2015-06-10  6:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-09 21:39 Pierre-Marie de Rodat
2015-06-10  7:06 ` Richard Biener [this message]
2015-06-10 13:09   ` Pierre-Marie de Rodat
2015-06-10 13:37     ` Richard Biener
2015-06-10 14:31       ` Pierre-Marie de Rodat
2015-06-11  8:02         ` Richard Biener
2015-06-11  9:10         ` Richard Biener
2015-06-11  9:21           ` Pierre-Marie de Rodat
2015-06-11  9:25             ` Richard Biener
2015-06-11 13:49               ` Pierre-Marie de Rodat
2015-06-12  1:25 David Edelsohn
2015-06-12  5:45 ` Richard Biener
2015-06-12 10:15   ` Pierre-Marie de Rodat
2015-06-12 10:32   ` Pierre-Marie de Rodat
2015-06-12 11:17     ` Richard Biener
2015-06-12 13:56       ` Pierre-Marie de Rodat

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.1506100855090.30088@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=derodat@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).