From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uGPRDdkV42DVYAAAWB0awg (envelope-from ) for ; Mon, 05 Jul 2021 10:23:21 -0400 Received: by simark.ca (Postfix, from userid 112) id 27EFD1F1F2; Mon, 5 Jul 2021 10:23:21 -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 332301E940 for ; Mon, 5 Jul 2021 10:23:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9B0913840008 for ; Mon, 5 Jul 2021 14:23:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B0913840008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1625494999; bh=TOtzQd6A5fqJJJP9UA6WYaDT+lNyKvjiyFwHClCiMhg=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=uPNdoJaAfaN8DWY+akilYpdwFzRlsihbDRNXHCcEnkGrIbxw4z9UIwSFrd0KMWTNg VHVA84hNz2Lz9Bw5kiu3tpPRMTMgC0Wa5o6gJGbjaTOSu2Kst4R9LSsVzW6jIy3oxo +e9B+VEtAcKf7akH5RtyL0GJaqMvp2SmpJLCc9/Y= 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 References: <26dd0f26-7e7f-c0e8-263b-ef65554a93de@polymtl.ca> <20210630151843.GC2568@embecosm.com> 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-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 Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > 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