public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Hafiz Abid Qadeer <abid_qadeer@mentor.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Thomas Schwinge <thomas@codesourcery.com>,
	Abid Qadeer <abidh@codesourcery.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.
Date: Tue, 27 Jul 2021 10:39:58 +0200	[thread overview]
Message-ID: <CAFiYyc2GxpQ_XM4bzeu4W1EvS1KJzJkg9oQEZP5G69CFN7VW3g@mail.gmail.com> (raw)
In-Reply-To: <33e9b2c3-7ab6-211b-253e-d2004af635c5@mentor.com>

On Mon, Jul 26, 2021 at 11:34 PM Hafiz Abid Qadeer
<abid_qadeer@mentor.com> wrote:
>
> On 22/07/2021 12:52, Richard Biener wrote:
> > On Thu, Jul 22, 2021 at 1:48 PM Jakub Jelinek <jakub@redhat.com> wrote:
> >>
> >> On Thu, Jul 22, 2021 at 01:43:49PM +0200, Richard Biener wrote:
> >>> So I think we need to get to an agreement between the debug info
> >>> producer and consumer here.
> >>> Usually the DWARF spec is not of much help here.
> >>
> >> It is something that needs to be discussed for DWARF 6, currently indeed can
> >> be solved only with some DWARF extensions we'd need to invent.
> >
> > I mean, the question is what should the concrete instance inherit from
> > the abstract instance - IMHO parent-child relationship is one thing, no?
>
> I guess the problem is that pointer is one-sided from concrete to abstract. With this change, one
> can go from concrete child function to abstract child (and abstract parent). But it is not easy to
> find the concrete parent for the consumer as there is no link from abstract to concrete.

Yes, that's true - there could be a one-to-many relationship there.  But then I
wonder in which case such lookup in the DIE tree would be the correct thing
to do.  If I lookup a variable from the parent then the concrete
instance of that
should be found by unwinding unless it is a static variable in which case
the lookup can be done in any of the concrete instances.

But then the original issue that the consumer skips the function if it doesn't
have a PC range and thus skips over childs looks like an invalid optimization.

Btw, the situation you run into can be simulated by

int main(int argc, char **argv)
{
  void foo ()
    {
      __builtin_puts ("bar");
    }
  foo ();
  return 0;
}

and compiling with -g -flto -flto-partition=max which forces main and foo
into different LTRANS units and get's us

 <1><114>: Abbrev Number: 2 (DW_TAG_subprogram)
    <115>   DW_AT_abstract_origin: <0x155>
 <2><119>: Abbrev Number: 3 (DW_TAG_subprogram)
    <11a>   DW_AT_abstract_origin: <0x179>
    <11e>   DW_AT_low_pc      : 0x400515
    <126>   DW_AT_high_pc     : 0x19
    <12e>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <130>   DW_AT_static_link : 4 byte block: 91 68 6 6         (DW_OP_fbreg: -2

gdb then fails to see 'foo' at all (cannot break on it) and the lookup of 'argc'
inside it fails (setting a breakpoint also fails without -flto-partition=max,
but I can print argc just fine).

I suggest you file a bug with gdb and see how that resolves.

Richard.

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

  reply	other threads:[~2021-07-27  8:40 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
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 [this message]
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=CAFiYyc2GxpQ_XM4bzeu4W1EvS1KJzJkg9oQEZP5G69CFN7VW3g@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=abid_qadeer@mentor.com \
    --cc=abidh@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).