public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Hafiz Abid Qadeer <abid_qadeer@mentor.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
	Abid Qadeer <abidh@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.
Date: Fri, 16 Jul 2021 21:23:10 +0100	[thread overview]
Message-ID: <adcc49f7-cc72-fd9b-a7ea-b409de3b68f8@mentor.com> (raw)
In-Reply-To: <CAFiYyc1C700U6tXK=N67_2N5WsXjJQtvwGKfqKNqXOHwfTzCFQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

On 15/07/2021 13:09, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
> <abid_qadeer@mentor.com> wrote:
>>
>> On 15/07/2021 11:33, Thomas Schwinge wrote:
>>>
>>>> Note that the "parent" should be abstract but I don't think dwarf has a
>>>> way to express a fully abstract parent of a concrete instance child - or
>>>> at least how GCC expresses this causes consumers to "misinterpret"
>>>> that.  I wonder if adding a DW_AT_declaration to the late DWARF
>>>> emitted "parent" would fix things as well here?
>>>
>>> (I suppose not, Abid?)
>>>
>>
>> Yes, adding DW_AT_declaration does not fix the problem.
> 
> Does emitting
> 
> DW_TAG_compile_unit
>   DW_AT_name    ("<artificial>")
> 
>   DW_TAG_subprogram // notional parent function (foo) with no code range
>     DW_AT_declaration 1
> a:    DW_TAG_subprogram // offload function foo._omp_fn.0
>       DW_AT_declaration 1
> 
>   DW_TAG_subprogram // offload function
>   DW_AT_abstract_origin a
> ...
> 
> do the trick?  The following would do this, flattening function definitions
> for the concrete copies:
> 
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 82783c4968b..a9c8bc43e88 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -6076,6 +6076,11 @@ maybe_create_die_with_external_ref (tree decl)
>    /* Peel types in the context stack.  */
>    while (ctx && TYPE_P (ctx))
>      ctx = TYPE_CONTEXT (ctx);
> +  /* For functions peel the context up to namespace/TU scope.  The abstract
> +     copies reveal the true nesting.  */
> +  if (TREE_CODE (decl) == FUNCTION_DECL)
> +    while (ctx && TREE_CODE (ctx) == FUNCTION_DECL)
> +      ctx = DECL_CONTEXT (ctx);
>    /* Likewise namespaces in case we do not want to emit DIEs for them.  */
>    if (debug_info_level <= DINFO_LEVEL_TERSE)
>      while (ctx && TREE_CODE (ctx) == NAMESPACE_DECL)
> @@ -6099,8 +6104,7 @@ maybe_create_die_with_external_ref (tree decl)
>         /* Leave function local entities parent determination to when
>            we process scope vars.  */
>         ;
> -      else
> -       parent = lookup_decl_die (ctx);
> +      parent = lookup_decl_die (ctx);
>      }
>    else
>      /* In some cases the FEs fail to set DECL_CONTEXT properly.
> 

Thanks. This solves the problem. Only the first hunk was required. Second hunk
actually causes an ICE when TREE_CODE (ctx) == BLOCK.
OK to commit the attached patch?


-- 
Hafiz Abid Qadeer
Mentor, a Siemens Business

[-- Attachment #2: 0001-DWARF-Fix-hierarchy-of-debug-information-for-offload.patch --]
[-- Type: text/x-patch, Size: 2134 bytes --]

From 8e886f8502784d3aafdaf7e9778ce21b8c8f3b93 Mon Sep 17 00:00:00 2001
From: Hafiz Abid Qadeer <abidh@codesourcery.com>
Date: Fri, 16 Jul 2021 21:00:37 +0100
Subject: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.

Currently, if we look at the debug information for offload kernel
regions, it looks something like this:

void foo (void)
{
  {

  }
}

DW_TAG_compile_unit
  DW_AT_name	("<artificial>")

  DW_TAG_subprogram // notional parent function (foo) with no code range

    DW_TAG_subprogram // offload function foo._omp_fn.0

There is an artificial compile unit. It contains a parent subprogram which
has the offload function as its child.  The parent function makes sense in
host code where it actually exists and does have an address range. But in
offload code, it does not exist and neither the generated dwarf has an
address range for this function.

When debugger read the dwarf for offload code, they see a function with no
address range and discard it alongwith its children which include offload
function.  This results in a poor debug experience of offload code.

This patch was suggested by Richard and it solves this problem by peeling
the parent function from the concrete copies.

gcc/

	* gcc/dwarf2out.c (maybe_create_die_with_external_ref): Remove function
	from the context chain.
---
 gcc/dwarf2out.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 561f8b23517..e2893bd91ed 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6121,6 +6121,11 @@ maybe_create_die_with_external_ref (tree decl)
   /* Peel types in the context stack.  */
   while (ctx && TYPE_P (ctx))
     ctx = TYPE_CONTEXT (ctx);
+  /* For functions peel the context up to namespace/TU scope.  The abstract
+     copies reveal the true nesting.  */
+  if (TREE_CODE (decl) == FUNCTION_DECL)
+    while (ctx && TREE_CODE (ctx) == FUNCTION_DECL)
+      ctx = DECL_CONTEXT (ctx);
   /* Likewise namespaces in case we do not want to emit DIEs for them.  */
   if (debug_info_level <= DINFO_LEVEL_TERSE)
     while (ctx && TREE_CODE (ctx) == NAMESPACE_DECL)
-- 
2.25.1


  reply	other threads:[~2021-07-16 20:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01 15:16 Hafiz Abid Qadeer
2021-07-02  7:15 ` Richard Biener
2021-07-15 10:33   ` Thomas Schwinge
2021-07-15 10:35     ` Hafiz Abid Qadeer
2021-07-15 12:09       ` Richard Biener
2021-07-16 20:23         ` Hafiz Abid Qadeer [this message]
2021-07-19 10:45           ` Richard Biener
2021-07-19 16:13             ` Hafiz Abid Qadeer
2021-07-19 16:41               ` Richard Biener
2021-07-21 17:55                 ` Hafiz Abid Qadeer
2021-07-22 11:43                   ` Richard Biener
2021-07-22 11:48                     ` Jakub Jelinek
2021-07-22 11:52                       ` Richard Biener
2021-07-26 21:34                         ` Hafiz Abid Qadeer
2021-07-27  8:39                           ` Richard Biener
2021-07-27 12:37                             ` Hafiz Abid Qadeer

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=adcc49f7-cc72-fd9b-a7ea-b409de3b68f8@mentor.com \
    --to=abid_qadeer@mentor.com \
    --cc=abidh@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.com \
    --cc=thomas@codesourcery.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).