From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60616 invoked by alias); 13 Jan 2016 12:17:30 -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 60599 invoked by uid 89); 13 Jan 2016 12:17:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=abstract, abstract_origin, sk:DW_AT_a, sk:dw_at_a X-HELO: mail-yk0-f172.google.com Received: from mail-yk0-f172.google.com (HELO mail-yk0-f172.google.com) (209.85.160.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 13 Jan 2016 12:17:28 +0000 Received: by mail-yk0-f172.google.com with SMTP id k129so463370040yke.0 for ; Wed, 13 Jan 2016 04:17:27 -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=QHWv786FUaMy9vVbGEcrS9ALM6DzHNTWad5+eaAJyiM=; b=QFvF/Rt0zNhmJbIsnYoBn78rmjsC0Exd7Jcl8dEgV0GGuNSPukZP2ONpjwoKQXvlOy Aimqheh6IQHdTwwEkJ3idiWgJTJTBTwZTK516DXMsePvoUGez3qVrkaD2EC0C31/KKfo UAndBckDm5ROF7El+88aDhnbYsVh5ZGb3fgvoe8ye9p9GYM/4OWX0dz9zX146eLT5dXZ zPjm5ndknZQsiQUcb5Frb/EP8qtQnX/IU4PllDOJUz0pT6ehlFAFH9qCWfvhUxREa50r lJarGcJIY7mL5GzE4TbXJd5h5vq965nQGuHl/uhPEDRPP8a6fcsLdrCDaajbLD2dKs9r FFKg== X-Gm-Message-State: ALoCoQnKb6v5dEWKXWWwzktdHu6L4bYJ7tkWNgYfcAHqWxGgTvItBhxCInaoKXqF/ZcJIPDNeyRx3y/qfkRMGtDUWKQPXBnu5Q== MIME-Version: 1.0 X-Received: by 10.13.203.71 with SMTP id n68mr99526114ywd.240.1452687445899; Wed, 13 Jan 2016 04:17:25 -0800 (PST) Received: by 10.37.202.82 with HTTP; Wed, 13 Jan 2016 04:17:25 -0800 (PST) In-Reply-To: <5695323E.3030700@adacore.com> References: <5695323E.3030700@adacore.com> Date: Wed, 13 Jan 2016 12:17: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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00809.txt.bz2 On Tue, Jan 12, 2016 at 6:05 PM, Pierre-Marie de Rodat wrote: > Hello, > > Although the following patch does not fix a regression, I believe it fixe= s a > bug visible from a debugger, so I think it=E2=80=99s a valid candidate at= this > stage. > > This change tracks from which abstract lexical block concrete ones come f= rom > in DWARF so that debuggers can inherit the former from the latter. This > enables debuggers to properly handle the following case: > > * function Child2 is nested in a lexical block, itself nested in > function Child1; > * function Child1 is inlined into some call site; > * function Child2 is never inlined. > > Here, Child2 is described in DWARF only in the abstract instance of Child= 1. > So when debuggers decode Child1's concrete instances, they need to fetch = the > definition for Child2 in the corresponding abstract instance: the > DW_AT_abstract_origin link on the lexical block that embeds Child1 enables > them to do that. > > Bootstrapped and regtested on x86_64-linux. > Ok to commit? Thank you in advance! I wonder if you can construct a guality testcase that passes with and fails without the patch? Anyway, the patch looks ok to me but please give others a chance to chime i= n. Thanks, Richard. > gcc/ChangeLog: > > * dwarf2out.c (add_abstract_origin_attribute): Adjust > documentation comment. For BLOCK nodes, add a > DW_AT_abstract_origin attribute that points to the DIE generated > for the origin BLOCK. > (gen_lexical_block_die): Call add_abstract_origin_attribute for > blocks from inlined functions. > --- > gcc/dwarf2out.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c > index da5524e..a889dbb 100644 > --- a/gcc/dwarf2out.c > +++ b/gcc/dwarf2out.c > @@ -18463,15 +18463,16 @@ add_prototyped_attribute (dw_die_ref die, tree > func_type) > } > /* Add an 'abstract_origin' attribute below a given DIE. The DIE is fo= und > - by looking in either the type declaration or object declaration > - equate table. */ > + by looking in the type declaration, the object declaration equate tab= le > or > + the block mapping. */ > static inline dw_die_ref > add_abstract_origin_attribute (dw_die_ref die, tree origin) > { > dw_die_ref origin_die =3D NULL; > - if (TREE_CODE (origin) !=3D FUNCTION_DECL) > + if (TREE_CODE (origin) !=3D FUNCTION_DECL > + && TREE_CODE (origin) !=3D BLOCK) > { > /* We may have gotten separated from the block for the inlined > function, if we're in an exception handler or some such; make > @@ -18493,6 +18494,8 @@ add_abstract_origin_attribute (dw_die_ref die, tr= ee > origin) > origin_die =3D lookup_decl_die (origin); > else if (TYPE_P (origin)) > origin_die =3D lookup_type_die (origin); > + else if (TREE_CODE (origin) =3D=3D BLOCK) > + origin_die =3D BLOCK_DIE (origin); > /* XXX: Functions that are never lowered don't always have correct bl= ock > trees (in the case of java, they simply have no block tree, in some > other > @@ -21294,6 +21297,10 @@ gen_lexical_block_die (tree stmt, dw_die_ref > context_die) > BLOCK_DIE (stmt) =3D stmt_die; > old_die =3D NULL; > } > + > + tree origin =3D block_ultimate_origin (stmt); > + if (origin !=3D NULL_TREE && origin !=3D stmt) > + add_abstract_origin_attribute (stmt_die, origin); > } > if (old_die) > -- > 2.3.3.199.g52cae64 >