From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zag4MRV0iWBLKAAAWB0awg (envelope-from ) for ; Wed, 28 Apr 2021 10:41:25 -0400 Received: by simark.ca (Postfix, from userid 112) id BB13D1F11C; Wed, 28 Apr 2021 10:41:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 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 10DF61E01F for ; Wed, 28 Apr 2021 10:41:25 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 54B5A3AA1401; Wed, 28 Apr 2021 14:41:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 54B5A3AA1401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619620884; bh=zEZinQobOKEgIGwnXv5lVQSPCIY6GMSW+RW6k9nimfE=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=ep7CyXbGZPev9IY5JFXV2mOERXctmwH5NcKaxTHsoLIVJRZs5YPW8yPEZg1wbb6HZ XzODvxv4rjmXx0Xp33v/uKJIramc8vmulsjg3tOLYRg1Ue1jyt/YAWMvWFkfLKIjWW KMyYeA1F6V5x4wQybyHpSBpzdF4NdtXiGvYRnOEU= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 8D8BF382E82E for ; Wed, 28 Apr 2021 14:41:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D8BF382E82E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13SEfEGi029896 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Apr 2021 10:41:19 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13SEfEGi029896 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C6ADE1E01F; Wed, 28 Apr 2021 10:41:14 -0400 (EDT) Subject: Re: [PATCH 16/43] Simplify dwarf_expr_context class interface To: Zoran Zaric , gdb-patches@sourceware.org References: <20210301144620.103016-1-Zoran.Zaric@amd.com> <20210301144620.103016-17-Zoran.Zaric@amd.com> Message-ID: <94a19b5a-1e38-53af-8b96-956f138f8303@polymtl.ca> Date: Wed, 28 Apr 2021 10:41:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 28 Apr 2021 14:41:14 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" >>> diff --git a/gdb/dwarf2/expr.h b/gdb/dwarf2/expr.h >>> index a0ac21f2ed1..d1374068732 100644 >>> --- a/gdb/dwarf2/expr.h >>> +++ b/gdb/dwarf2/expr.h >>> @@ -119,19 +119,30 @@ struct dwarf_stack_value >>> its current state and its callbacks. */ >>> struct dwarf_expr_context >>> { >>> - dwarf_expr_context (dwarf2_per_objfile *per_objfile); >>> + /* We should ever only pass in the PER_OBJFILE, while the ADDR_SIZE >>> + information should be retrievable from there. The PER_OBJFILE >>> + contains a pointer to the PER_BFD information anyway and the >>> + address size information must be the same for the whole BFD. */ >>> + dwarf_expr_context (struct dwarf2_per_objfile *per_objfile, >>> + int addr_size); >> >> I don't really understand the comment. What do you mean by "We should >> ever only pass..."? In general, I don't find that the comment helps me >> understand what the parameters are and do. Try to change it to be more >> concrete and straight to the point. > > This was more me venting about that particular design choice Haha, it indeed did feel this way. > because the reality is that an address size has to be consistent with what is defined in the original object file but there is no interface to always get it in a clean way in gdb. In this case, it looks like it's because an expression can come from a DIE attribute, directly linked to a CU. So the address size comes from that CU's header. And at other times, the expression comes from a frame description entry (FDE) / common information entry (CIE), so the address size comes from that CIE's header. So I don't see any other easy way than making the caller provide it. > It makes sense for me to remove that comment altogether in the next iteration and thing about a future change that would clean it up. Ok. Or, just make a simple comment. You could say that ADDRESS_SIZE is the address size coming from the CU's header or the CIE's header, depending on the context. Anyway, this is all perhaps subject to change if I understand correctly. In the end do you still expose a class, or just one function, to evaluate a DWARF expression? Simon