public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pierre-Marie de Rodat <derodat@adacore.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: [PATCH] DWARF: add abstract origin links on lexical blocks DIEs
Date: Tue, 12 Jan 2016 17:05:00 -0000	[thread overview]
Message-ID: <5695323E.3030700@adacore.com> (raw)

Hello,

Although the following patch does not fix a regression, I believe it 
fixes a bug visible from a debugger, so I think it’s a valid candidate 
at this stage.

This change tracks from which abstract lexical block concrete ones come 
from in DWARF so that debuggers can inherit the former from the latter. 
This enables debuggers to properly handle the following case:

   * function Child2 is nested in a lexical block, itself nested in
     function Child1;
   * function Child1 is inlined into some call site;
   * function Child2 is never inlined.

Here, Child2 is described in DWARF only in the abstract instance of 
Child1. So when debuggers decode Child1's concrete instances, they need 
to fetch the definition for Child2 in the corresponding abstract 
instance: the DW_AT_abstract_origin link on the lexical block that 
embeds Child1 enables them to do that.

Bootstrapped and regtested on x86_64-linux.
Ok to commit? Thank you in advance!

gcc/ChangeLog:

	* dwarf2out.c (add_abstract_origin_attribute): Adjust
	documentation comment.  For BLOCK nodes, add a
	DW_AT_abstract_origin attribute that points to the DIE generated
	for the origin BLOCK.
	(gen_lexical_block_die): Call add_abstract_origin_attribute for
	blocks from inlined functions.
---
  gcc/dwarf2out.c | 13 ++++++++++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index da5524e..a889dbb 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -18463,15 +18463,16 @@ add_prototyped_attribute (dw_die_ref die, tree 
func_type)
  }
   /* Add an 'abstract_origin' attribute below a given DIE.  The DIE is 
found
-   by looking in either the type declaration or object declaration
-   equate table.  */
+   by looking in the type declaration, the object declaration equate 
table or
+   the block mapping.  */
   static inline dw_die_ref
  add_abstract_origin_attribute (dw_die_ref die, tree origin)
  {
    dw_die_ref origin_die = NULL;
  -  if (TREE_CODE (origin) != FUNCTION_DECL)
+  if (TREE_CODE (origin) != FUNCTION_DECL
+      && TREE_CODE (origin) != BLOCK)
      {
        /* We may have gotten separated from the block for the inlined
  	 function, if we're in an exception handler or some such; make
@@ -18493,6 +18494,8 @@ add_abstract_origin_attribute (dw_die_ref die, 
tree origin)
      origin_die = lookup_decl_die (origin);
    else if (TYPE_P (origin))
      origin_die = lookup_type_die (origin);
+  else if (TREE_CODE (origin) == BLOCK)
+    origin_die = BLOCK_DIE (origin);
     /* XXX: Functions that are never lowered don't always have correct 
block
       trees (in the case of java, they simply have no block tree, in 
some other
@@ -21294,6 +21297,10 @@ gen_lexical_block_die (tree stmt, dw_die_ref 
context_die)
  	  BLOCK_DIE (stmt) = stmt_die;
  	  old_die = NULL;
  	}
+
+      tree origin = block_ultimate_origin (stmt);
+      if (origin != NULL_TREE && origin != stmt)
+	add_abstract_origin_attribute (stmt_die, origin);
      }
     if (old_die)
-- 
2.3.3.199.g52cae64

             reply	other threads:[~2016-01-12 17:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-12 17:05 Pierre-Marie de Rodat [this message]
2016-01-13 12:17 ` Richard Biener
2016-01-15 14:41   ` Pierre-Marie de Rodat
2016-01-15 15:53     ` Richard Biener
2016-01-17 20:09       ` Eric Botcazou
2016-01-18  9:36         ` Richard Biener
2016-01-18  9:45           ` Eric Botcazou
2016-01-18  9:47             ` Pierre-Marie de Rodat
2016-01-20  9:47               ` Pierre-Marie de Rodat
2016-04-26  8:00                 ` [PING][PATCH] " Pierre-Marie de Rodat
2016-05-04 14:23                   ` [PING*2][PATCH] " Pierre-Marie de Rodat
2016-05-09 11:02                     ` Richard Biener
2016-05-10  8:04                       ` 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=5695323E.3030700@adacore.com \
    --to=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).