From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66562 invoked by alias); 15 Jan 2016 15:53:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66525 invoked by uid 89); 15 Jan 2016 15:53:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:parent.child, reproducer, rodat, PierreMarie X-HELO: mail-yk0-f179.google.com Received: from mail-yk0-f179.google.com (HELO mail-yk0-f179.google.com) (209.85.160.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 15 Jan 2016 15:53:53 +0000 Received: by mail-yk0-f179.google.com with SMTP id x67so548668149ykd.2 for ; Fri, 15 Jan 2016 07:53:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BwUDy6WMC1UatFRI7BldRZjNPfnZQgbDXHG4qt83xcQ=; b=FEdcf0zXVvo11wwC1GdpDbmpF752ZBCJIRB1OyUpFsZfVw8TCrx8rkhCnYuPuApyYt EXJ8PvG3uyeR1D8AAMx/4T/vHgSWoQ7SwTUTqJK/+Zl0CBYu3Ij2L3bM3YnOVwwtH/as 4kTAnBbrR4KfrMxE7dJ++ln9TE4L/HR9zaPXdqynG1QEw/psPDG6iZ/h2/1nrnjFTyeB 2TUiSCONTLAU5+Ta+q0fBJ60W05vGCU4YCU1o2H6nIOaM3n12EUQpuEhdWoKcut0osjw cEStJ33vEVq+VRvI/xS2lOrJajhVRSSEBawlK/dkq4kmXCDwJQoYfEcnmVRRq82X64ii oOfw== X-Gm-Message-State: ALoCoQla0YraJmxXBdfTHeoMZgTI4lITgvyyTKrd4/nF0LWQki7FhGAhfN9cKmyGq5Udt38ZfsfFMSzWEYiA5ElQxpRIiQgYPg== MIME-Version: 1.0 X-Received: by 10.129.20.212 with SMTP id 203mr8160011ywu.68.1452873231281; Fri, 15 Jan 2016 07:53:51 -0800 (PST) Received: by 10.37.202.82 with HTTP; Fri, 15 Jan 2016 07:53:51 -0800 (PST) In-Reply-To: <56990512.7070808@adacore.com> References: <5695323E.3030700@adacore.com> <56990512.7070808@adacore.com> Date: Fri, 15 Jan 2016 15:53:00 -0000 Message-ID: Subject: Re: [PATCH] DWARF: add abstract origin links on lexical blocks DIEs From: Richard Biener To: Pierre-Marie de Rodat Cc: GCC Patches , Eric Botcazou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01090.txt.bz2 On Fri, Jan 15, 2016 at 3:41 PM, Pierre-Marie de Rodat On 01/13/2016 01:17 PM, Richard Biener wrote: >> >> I wonder if you can construct a guality testcase that passes with and >> fails without >> the patch? > > > I=E2=80=99ve tried to first look at how guality testcases are written (th= anks for > your answers on IRC, by the way :-)) and then how I could write a testcase > for my fix. It seems there are two ways: match patterns in the assembly f= ile > or evaluate an expression in GDB. > > I already have the testcase I used during development: it=E2=80=99s writt= en in Ada, > to build with -O2. The way it checks the fix is to see if GDB manages to = put > a breakpoint on the Child2 symbol before executing the program (it cannot > before my fix and it can afterwards). Oh, and it requires a fairly recent > GDB version (7.10 looks good). > > I managed to get a similar GNU C99 reproducer (it=E2=80=99s attached): th= e debugging > information has the pattern that exhibits the bugfix. Namely: while the > =E2=80=9Cparent=E2=80=9D function is inlined, the =E2=80=9Cchild=E2=80=9D= function (which is in a block > inside =E2=80=9Cparent=E2=80=9D) is not. So GDB relies on the DW_TAG_abst= ract_origin in the > inlined block to refer to the abstract block that contains the DIE that > materializes =E2=80=9Cchild=E2=80=9C. > > However, it looks like there is no way in GDB to refer to C nested functi= ons > when they are not in the current scope: >> >> $ gcc -g -O2 -std=3Dgnu99 nested_fun.c nested_fun_helpers.c >> $ gdb -n -q ./a.out >> (gdb) ptype child >> No symbol "child" in current context. >> (gdb) ptype nested_fun.parent.child >> No symbol "nested_fun" in current context. > > > On the other hand, this works with the Ada testcase: >> >> (gdb) ptype nested_fun.parent.child >> type =3D (false, true) > > > So I=E2=80=99m not sure what to do next: should I do a fragile testcase b= ased on > scanning the assembly file? (it could break with an optimizer change) cre= ate > a guality testsuite for Ada? Sounds like a good excuse to add a guality for Ada (which has unique needs for dwarf). Richard. >> Anyway, the patch looks ok to me but please give others a chance to chime >> in. > > > Sure. Thank you for reviewing! > > -- > Pierre-Marie de Rodat