From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1185B3858031 for ; Mon, 5 Jul 2021 14:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1185B3858031 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 165EMrIh026261 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 5 Jul 2021 10:22:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 165EMrIh026261 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 B58151E940; Mon, 5 Jul 2021 10:22:53 -0400 (EDT) Subject: Re: [PATCHv2 2/2] gdb: remove VALUE_FRAME_ID To: Andrew Burgess Cc: gdb-patches@sourceware.org References: <26dd0f26-7e7f-c0e8-263b-ef65554a93de@polymtl.ca> <20210630151843.GC2568@embecosm.com> From: Simon Marchi Message-ID: <68db253b-9d19-87fc-8060-3e65b0cff394@polymtl.ca> Date: Mon, 5 Jul 2021 10:22:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210630151843.GC2568@embecosm.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 Mon, 5 Jul 2021 14:22:53 +0000 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 05 Jul 2021 14:23:01 -0000 > It was unexpected to me :) > > The frame number being reported here is the frame that wants the > register, not the frame that provides the register, so given a stack > like this (now with frame numbers): > > #1:normal_frame -> #0:inline_frame -> #-1:sentinel_frame > > And GDB says: > > { value_fetch_lazy (frame=1,regnum=....... > > GDB is trying to say that frame #1 asked to read a register, and the > value returned as .... whatever .... > > BUT, what we _actually_ end up saying is: > > { value_fetch_lazy (frame=0,regnum=....... > > Which just isn't correct, frame 0 didn't cause the lazy register value > to be created, frame 1 did. A developer reading these logs needs to > understand that frame 0 is inline, and that the value in frame 1 is > the same as the value in frame 0. > > You are correct that the patch you linked is indeed what introduced > this mess in the first place, but I think the reasoning behind that > original patch is still good. > > If this makes more sense then I will update the commit message to > hopefully make things clearer - what do you think? Ok, I (think) I see what you mean. I think we could adjust the debug print to print the next frame's (which supplies the values) level instead (and make it clear that it's the next frame's level that we print). Simon