From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dZKBHwa4SWO0WAwAWB0awg (envelope-from ) for ; Fri, 14 Oct 2022 15:27:02 -0400 Received: by simark.ca (Postfix, from userid 112) id 70BFF1E112; Fri, 14 Oct 2022 15:27:02 -0400 (EDT) Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=MrQe31ji; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DC4051E0D3 for ; Fri, 14 Oct 2022 15:27:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B62B93858023 for ; Fri, 14 Oct 2022 19:27:00 +0000 (GMT) Received: from alt-proxy28.mail.unifiedlayer.com (alt-proxy28.mail.unifiedlayer.com [74.220.216.123]) by sourceware.org (Postfix) with ESMTPS id 3B89C3858D38 for ; Fri, 14 Oct 2022 19:26:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B89C3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id 605E91003FBD4 for ; Fri, 14 Oct 2022 19:26:36 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id jQKJoAeoaCeXyjQKKoKoQE; Fri, 14 Oct 2022 19:26:36 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Qv+bYX+d c=1 sm=1 tr=0 ts=6349b7ec a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=Qawa6l4ZSaYA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=hBxS4ylpqGWQjpLb_WYA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6B9q5ntg3pV0wBYozyuJCFoz7g8AnxclJZEqMCzLQhQ=; b=MrQe31jiv73Wk58tQbZMCaXKAu isrbTaH6D14cOz7t8OELQgruDbp19jzIsQw3YQ6GGX1iR0WYVp6ZrbjOQvvKWBtUrid7hzj1e6Hmh OJDIoH1GA/AqjO4b8DZ73/bO9; Received: from 71-211-160-49.hlrn.qwest.net ([71.211.160.49]:56692 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ojQKI-001EUq-6O; Fri, 14 Oct 2022 13:26:34 -0600 From: Tom Tromey To: "Sharma, Alok Kumar via Gdb-patches" Subject: Re: [PATCH] Enable Access to containing scope variables from nested inlined function References: X-Attribution: Tom Date: Fri, 14 Oct 2022 13:26:28 -0600 In-Reply-To: (Alok Kumar via Gdb-patches Sharma's message of "Sun, 24 Jul 2022 18:16:23 +0000") Message-ID: <87wn92kxzv.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.160.49 X-Source-L: No X-Exim-ID: 1ojQKI-001EUq-6O X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-160-49.hlrn.qwest.net (murgatroyd) [71.211.160.49]:56692 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "George, Jini Susan" , "Sharma, Alok Kumar" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" >>>>> Sharma, Alok Kumar via Gdb-patches writes: > The gcc compiler supports nested (local scoped) function for end user, > the Clang compiler does not allow nested function for end user but > compiler itself generates such artificial functions internally ( in > case of Openmp). General barrier by gdb reduces debug experience, > current patch enhances debugging in such cases. It seems to me that allowing access to the locals of the enclosing function will yield weird behavior in some situations, for example when the enclosing function shadows some global variable. Is there any way to detect specifically this Openmp case and only implement this behavior for it? > +/* Data structure to contain DIE, generated BLOCK for it and in case > + DIE is inlined its ORIG_DIE which is DIE represented by the > + DW_AT_abstract_origin attribute. */ > + > +struct die_block > + { > + struct die_info *die; > + struct die_info *orig_die; > + struct block *block; > + }; > + > +/* List of DIE_BLOCKs */ > + > +struct die_block_list > + { > + struct die_block_list *next; > + struct die_block mem; > + }; You definitely don't want to reference die_info from generic code. There's other issues with this part of the patch but I am hoping it's just not needed. > diff --git a/gdb/symtab.h b/gdb/symtab.h > index ac902a4cbbe..0f765e2aec3 100644 > --- a/gdb/symtab.h > +++ b/gdb/symtab.h > @@ -1399,6 +1409,10 @@ struct symbol : public general_symbol_info, public allocate_on_obstack > void set_symtab (struct symtab *symtab); > + /* Original scope (before inlining) block of inlined function. */ > + > + struct block *m_scopeblock; > + Adding a field to struct symbol also should be avoided. Isn't this information already implicit in the block nesting? Tom