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: Wed, 21 Jul 2021 18:55:36 +0100	[thread overview]
Message-ID: <28f299d1-93d5-ff33-1a83-41f373d3d1f7@mentor.com> (raw)
In-Reply-To: <6C66F8F4-71EC-431E-A0C5-737BBB9D84F3@gmail.com>

On 19/07/2021 17:41, Richard Biener wrote:
> On July 19, 2021 6:13:40 PM GMT+02:00, Hafiz Abid Qadeer <abid_qadeer@mentor.com> wrote:
>> On 19/07/2021 11:45, Richard Biener wrote:
>>> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
>>> <abid_qadeer@mentor.com> wrote:
>>>>
>>>> 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?
>>>
>>> I think we need to merge the TYPE_P peeling and FUNCTION_DECL peeling
>> into
>>> one loop since I suppose we can have a nested function in class
>> scope.
>>> So sth like
>>>
>>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>>> index 82783c4968b..61228410b51 100644
>>> --- a/gcc/dwarf2out.c
>>> +++ b/gcc/dwarf2out.c
>>> @@ -6073,8 +6073,12 @@ maybe_create_die_with_external_ref (tree decl)
>>>      }
>>>    else
>>>      ctx = DECL_CONTEXT (decl);
>>> -  /* Peel types in the context stack.  */
>>> -  while (ctx && TYPE_P (ctx))
>>> +  /* Peel types in the context stack.  For functions peel the
>> context up
>>> +     to namespace/TU scope.  The abstract copies reveal the true
>> nesting.  */
>>> +  while (ctx
>>> +        && (TYPE_P (ctx)
>>> +            || (TREE_CODE (decl) == FUNCTION_DECL
>>> +                && TREE_CODE (ctx) == FUNCTION_DECL)))
>>>      ctx = TYPE_CONTEXT (ctx);
>>>    /* Likewise namespaces in case we do not want to emit DIEs for
>> them.  */
>>>    if (debug_info_level <= DINFO_LEVEL_TERSE)
>>>
>> This causes an ICE,
>> internal compiler error: tree check: expected class 'type', have
>> 'declaration' (function_decl)
>>
>> Did you intend something like this:
>>
>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>> index 561f8b23517..c61f0041fba 100644
>> --- a/gcc/dwarf2out.c
>> +++ b/gcc/dwarf2out.c
>> @@ -6121,3 +6121,8 @@ maybe_create_die_with_external_ref (tree decl)
>> -  /* Peel types in the context stack.  */
>> -  while (ctx && TYPE_P (ctx))
>> -    ctx = TYPE_CONTEXT (ctx);
>> +  /* Peel types in the context stack.  For functions peel the context
>> up
>> +     to namespace/TU scope.  The abstract copies reveal the true
>> nesting.  */
>> +  while (ctx
>> +       && (TYPE_P (ctx)
>> +           || (TREE_CODE (decl) == FUNCTION_DECL
>> +               && TREE_CODE (ctx) == FUNCTION_DECL)))
>> +    ctx = TYPE_P (ctx) ? TYPE_CONTEXT (ctx) : DECL_CONTEXT (ctx);
>> +
> 
> Yes, of course. 
> 
>>
>>> if that works it's OK.  Can you run it on the gdb testsuite with
>> -flto added
>>> as well please (you need to do before/after comparison since IIRC
>> adding
>>> -flto will add a few fails).

GDB testsuite shows some extra fails which mainly happen because testcase assumes that you can
access the local variable of enclosing function from the nested function (or omp parallel region).
After this change, the nested functions are no longer children of the enclosing function so those
tests fail.

The problem that prompted this patch happened for parent function that did not have a code range i.e
a notional parent.  I was wondering if we should update the ctx only for such parents instead of all
function as we did above.

Thanks,
-- 
Hafiz Abid Qadeer
Mentor, a Siemens Business

  reply	other threads:[~2021-07-21 17:55 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
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 [this message]
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=28f299d1-93d5-ff33-1a83-41f373d3d1f7@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).