From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id D2188397281B for ; Tue, 27 Jul 2021 08:40:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2188397281B Received: by mail-ej1-x632.google.com with SMTP id o5so20916660ejy.2 for ; Tue, 27 Jul 2021 01:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TnZaE3Yfiz3kQlBN6QI0LE+ENmeNBURbNNt+HOblFg4=; b=ajvmjDNJsWwonXaMLSxLhtdlwgKQSp64CaZwnfwtIliO25MGEQvrxF71QCdhjL3OY4 TLzAcawiuQ03guUwKXAyIarvSL2OtjFiDWtaDQHFmMeJYVA9xuqobOUnSCONA128eY8Z ijitilZ+3VYBWVnQD9uHujB/JfmHKG+TJt1xc25qnzNfqldHPiE4fvA4uBP1jJMZhqyy X64oIoODNtVuW7ueduwSr9yNcQaH+YbHZ6vKwOisCFcTA2q09zqPNSLsys6ce1lqdGJB Ie2w41Qe0JDPpVCqPS59ErSy+WFIi9IbEfmH8j25Oyrt4FTGkLfcHP/zPO3WicgrLbVT D72A== X-Gm-Message-State: AOAM532GEVx21Lajby6EPVLrPM+43RCstn7o8R6pXiEecjwDUcxQiyhu zKSX8JRGs4g7SLfR/K9A7Ee7LKudF20t8jw1y6c= X-Google-Smtp-Source: ABdhPJyXn+dsfsm+ErvSAzaxykLCNMTP39fW5dC1PRj0hOlmv4PPpavOfXNi7N1Bdue9IfNug7Ta9fHMZ6c0qODoC9g= X-Received: by 2002:a17:906:4c89:: with SMTP id q9mr20964728eju.118.1627375208747; Tue, 27 Jul 2021 01:40:08 -0700 (PDT) MIME-Version: 1.0 References: <8735sfamu7.fsf@dem-tschwing-1.ger.mentorg.com> <50d1657e-c5de-9cb9-1aaa-233f27dfe9b9@mentor.com> <210da16b-5992-7d7f-7223-4a4f08998d49@mentor.com> <6C66F8F4-71EC-431E-A0C5-737BBB9D84F3@gmail.com> <28f299d1-93d5-ff33-1a83-41f373d3d1f7@mentor.com> <20210722114815.GT2380545@tucnak> <33e9b2c3-7ab6-211b-253e-d2004af635c5@mentor.com> In-Reply-To: <33e9b2c3-7ab6-211b-253e-d2004af635c5@mentor.com> From: Richard Biener Date: Tue, 27 Jul 2021 10:39:58 +0200 Message-ID: Subject: Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels. To: Hafiz Abid Qadeer Cc: Jakub Jelinek , Thomas Schwinge , Abid Qadeer , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 08:40:11 -0000 On Mon, Jul 26, 2021 at 11:34 PM Hafiz Abid Qadeer wrote: > > On 22/07/2021 12:52, Richard Biener wrote: > > On Thu, Jul 22, 2021 at 1:48 PM Jakub Jelinek 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