From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id onl1DtB1iWB6KAAAWB0awg (envelope-from ) for ; Wed, 28 Apr 2021 10:48:48 -0400 Received: by simark.ca (Postfix, from userid 112) id 292F91F11C; Wed, 28 Apr 2021 10:48:48 -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 7CBC21E01F for ; Wed, 28 Apr 2021 10:48:47 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2EEF43A7800B; Wed, 28 Apr 2021 14:48:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2EEF43A7800B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619621327; bh=ajLDiPaiZ629ubc5osQffJShp6xbhgrteIT9GzseDfc=; 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=EFVpdtC6QEDTXrtOSGQexVwaumschGKtyscoyHYvl41nIrjuWcY7fH22I0rrtvuis 8hwNE7mf1y9KYcFizIPhNhEBnHAJVNmjWAUujpdRz0MsevOc+raLq4XcfwHxtMRyn8 IeYYQRW5B8E9nCFk/adoI2lt+Y4w41MCzVaNm5us= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 611143AA1420 for ; Wed, 28 Apr 2021 14:48:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 611143AA1420 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 13SEmbC7003170 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Apr 2021 10:48:41 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13SEmbC7003170 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 298811E01F; Wed, 28 Apr 2021 10:48:37 -0400 (EDT) Subject: Re: [PATCH 18/43] Add new register access interface to expr.c To: Zoran Zaric , gdb-patches@sourceware.org References: <20210301144620.103016-1-Zoran.Zaric@amd.com> <20210301144620.103016-19-Zoran.Zaric@amd.com> <438db2e3-c39c-311a-a915-e13843085f02@amd.com> Message-ID: Date: Wed, 28 Apr 2021 10:48:36 -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: <438db2e3-c39c-311a-a915-e13843085f02@amd.com> 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:48:37 +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" >> Can regsize really be 0? > > This was part of the previously used API so my guess is that it could :) > > I didn't want to presume to many things if the previous code handled them. Ok, it's fine to keep it then, to avoid breaking some potential existing use case (we could try to remove it, but as a separate work). I ask these things because if things are not supposed to happen, it's better that we gdb_assert them, rather than handle them like this. Otherwise, when somebody comes around to read that code later, they will think that regsize == 0 (or frame == NULL in the other case) is a possibility, so that makes their mental model unnecessarily more complex. It can also cover some bugs which would be exposed by a failed assertion. >> I don't understand the code and how it relates to the comment. What >> does it mean for a register to be inside an offset? The expression >> `offset + length > regsize` checks that the end of the portion we want >> to read is beyond the end of the register. But there could be a part of >> the portion we want to read that is within the register. The code might >> be correct, but the comment needs to express the intention more clearly. > > This is not allowed in DWARF. The whole length needs to be contained in a register. If only some parts of it are then the location needs to be a composite and that is not covered with this low level interface. > > I should probably explicitly say that in the comment in the next iteration Ok, the existing comment makes it sound like "if what we want to read is _wholly_ outside of the register, we can return early". So just an optimization things. So yeah I think the comments needs to be clearer. >> Is `numregs < regnum` really useful? When would you encounter that? >> >> Simon >> > > This check was part of the previous interface as well. Maybe the interface was design to be conservative or maybe there was an use case where compiler generated something that resulted in an invalid regnum? > > Better safe then sorry I guess but, I can remove it if it doesn't make sense. If it was already there (I didn't find it though), then it's ok to keep it. Simon