From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" Cc: "Sharma, Alok Kumar" , "George, Jini Susan" 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-Spam-Status: No, score=-3028.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 14 Oct 2022 19:26:49 -0000 >>>>> 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