From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pY6kJyrWTGpI2ioAWB0awg (envelope-from ) for ; Tue, 07 Jul 2026 06:34:18 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UfIRsC3A; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9132B1E070; Tue, 07 Jul 2026 06:34:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id F23361E070 for ; Tue, 07 Jul 2026 06:34:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7BE734BA2E19 for ; Tue, 7 Jul 2026 10:34:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7BE734BA2E19 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UfIRsC3A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6F8554BA5435 for ; Tue, 7 Jul 2026 10:33:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6F8554BA5435 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6F8554BA5435 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783420422; cv=none; b=Z6ODDfFXlFKtHdaYlzdWZ6+GnH9fnGoHnpfkDDv5f8htjo069nQUV3bBKnO3//0XcL1t7uDsbV50B6CzqZI3CKlnAFcrlhO2xo1zMhpAEWZGfsLCgQrfNB2C9WxP13iCy9S6ZWhwxIlKAHWq6fM6fGXqMPmNTeK49Es60AtYuw8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783420422; c=relaxed/simple; bh=W1/fRBfvDZ1kp3XmHoQ87ZOoxYTOIWEFjuCDCXr8jfs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=r5WBwM6Hzpjl37BUcoCwXDWYjwQlv8gmX5F1U9U0AHM7rtrL9vW9FJkcS/4YEjJ+3ihe9icvXMHThGFJDlTFwt4gE6z+JYodC4njWFCdbDHvl01CwkNMzK72hhHIvU7eT5dmMufaUOBHzKMpt1RG4qP7bmv0o45tnPZcfudy80k= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UfIRsC3A DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F8554BA5435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783420422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tOrZPVFi+OjIQcGNQj3Z1uQmhqimuMdska++7MUohwY=; b=UfIRsC3AAcHiqzf2MDBeg/OcfGaFxIGdsWFXXTuLFpeTM4ryVisQxUfHG8j+xX/DLHXSpY XIwH/tnjuWgcvev1n5xCkmxbkg76gu+Q4/pNoRKpb7ZBFpWT0jh/qngqFDI5lH1QljrI9H TexlIzdCOXh7eqrd04+GcP3hqrNBIOc= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-170-VzYBBt8qNj2Yy7QhpMm4qA-1; Tue, 07 Jul 2026 06:33:40 -0400 X-MC-Unique: VzYBBt8qNj2Yy7QhpMm4qA-1 X-Mimecast-MFC-AGG-ID: VzYBBt8qNj2Yy7QhpMm4qA_1783420419 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-490a767b782so31541585e9.2 for ; Tue, 07 Jul 2026 03:33:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783420419; x=1784025219; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=tOrZPVFi+OjIQcGNQj3Z1uQmhqimuMdska++7MUohwY=; b=bRhpT0PZp3UdQ84rBW5rHizh2R9sqon1yXKyXMkGLTjjVV56n06aCvF14am38+wsRl NOZ+JQtwLCSF1hRGKarN+7k97j5TpDaVoVy8wrcRgWcgReWq7GK0GK4ACS2Rl96ZlW4o JW6eFbrs70FyGVUlpQrw3mZ5WL4pLVeSg6yBTuDxfB4vmJHbJoN1KfoMvNF7CzfgQdPR LedlqlchE6aOc/C0gW9ZaaSmuejTsYSwiNiRJg52SIlgozGMmkTwjy0W7o1MqWYwBOLT TjJRGnsXLl18VMEK/0cIFAM6/tKizGRF2GIzpCwJzCbw9WcYgDkGNofgBIIMxNEzsZWw +vlg== X-Gm-Message-State: AOJu0YyZupYVX3RC5//cgTg3ABLk3mCE+B81jsGjbUS3ri+khgHeaR+A 43KKnt/01O3QiE7wiuzl5ws8qEdqHa3CPWJo3yiXWL9f1URiGk4qy76hZxgNOaEr4P9Q5cYt53A BC0L3pwsWcYYpyk8HZQBgSaQWp8uBiB2yrhy3EuwS+SnPxOjkF0d4QKdEagCs+mybw80wwfA= X-Gm-Gg: AfdE7ck+x7OMfD+BP9hZ3onaACg2TYRuaIQyA+HCnkfw1dLrO6x+wMZlTqeSXG8N7Jn IDmwteV234pWon5U/3Y4VsOm4Wz41gXT8fe/2m1ukSWbGw+GsecLabo/Xn75iD40oDW2+AJ5pTs 9PhHAAzjXGw5TKkJ4q4G3OR0JRb8BcwEwJjnsTKSPz7phem+fTPAu5Ni0mVRcKFYnzKw3MfpIYX BGDvsvIm0HgkkbRNydGB1DJQEsBMO+adS/rtJOg2LjVCRXSqvwl7kK2ffgLiLu8cxAjUc9/MH9l 4+NW5VQBAf+g7NCEXj2XYtpcZXKpryxBpmxo7S5xyewdTzrh08QUaAUnej7i8wmF4B5ZXSXVTVi HfOwHqh0= X-Received: by 2002:a05:600c:c168:b0:48f:d5b8:5b07 with SMTP id 5b1f17b1804b1-493df065f7emr50892015e9.20.1783420419397; Tue, 07 Jul 2026 03:33:39 -0700 (PDT) X-Received: by 2002:a05:600c:c168:b0:48f:d5b8:5b07 with SMTP id 5b1f17b1804b1-493df065f7emr50891455e9.20.1783420418847; Tue, 07 Jul 2026 03:33:38 -0700 (PDT) Received: from localhost ([31.111.209.233]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9e4d83bdsm33550304f8f.13.2026.07.07.03.33.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 03:33:38 -0700 (PDT) From: Andrew Burgess To: "Rohr, Stephan" , Tom Tromey Cc: "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] gdb: set the cache information in 'get_prev_frame_maybe_check_cycle' In-Reply-To: References: <20260625145850.3104079-1-stephan.rohr@intel.com> <20260625145850.3104079-2-stephan.rohr@intel.com> <87se69wdbt.fsf@tromey.com> Date: Tue, 07 Jul 2026 11:33:37 +0100 Message-ID: <87tsqbt7ge.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ZmeLy3Um3QJWN8xRk37NkMAlEBIOWuvrmlU4un9KhX4_1783420419 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org "Rohr, Stephan" writes: > Hi Tom, > > thank you for your feedback! I will fix the typos in v2 of the patch. > > I'll try to explain the problem in more detail now: > > 1. If you run an inferior call after the up command invalidates > the selected frame. > 2. The selected frame is rebuild following the chain > > get_selected_frame () -> lookup_selected_frame () > -> get_prev_frame_always_1 () > -> get_prev_frame_maybe_check_cycle () > > 3. At this point, the frame_info_ptr is constructed before the > frame-id is computed. The cache Information is not updated as > 'compute_frame_id' only updates the frame id of the internal > 'frame_info' pointer. > > 4. If we now run the "frame" command in combination with a > pretty-printer, this invokes another infcall to evaluate the > pretty-printer. > > 5. This clears the 'm_ptr' member of the frame_info_ptr. Since the cache > id is not set, a subsequent reinflate fails. > > A very simple fix for this could be: > > @@ -2332,7 +2361,7 @@ get_prev_frame_maybe_check_cycle (const frame_info_ptr &this_frame) > throw; > } > > - return prev_frame; > + return frame_info_ptr (prev_frame.get ()); > } > > It constructs a new frame_info_ptr using the updated raw pointer > of 'prev_frame'. This is somewhat redundant as another frame_info_ptr > is added to the frame list in the frame_info_ptr ctor. > > The frame list entry from > > frame_info_ptr prev_frame = get_prev_frame_raw (this_frame); > > is removed again by the frame_info_ptr's dtor. > > This would add some overhead. > > I didn't find a better solution. We could modify 'get_prev_frame_raw' to > return a raw pointer instead (it is the only location where is this called at > all). But we'd need a temporary copy of the frame_info_ptr anyways, > either to pass a frame_info_ptr to 'compute_frame_id' or inside of > 'compute_frame_id' (to forward the frame id to > 'frame_unwind_find_by_frame'). Changing these functions to > accept a raw frame_info pointer is not desired in my point of view. I'd like to dig into this a little more. Why do you feel changing these to take a raw pointer would be a bad thing? Looking at the code again, I don't think it makes much sense to have these take a frame_info_ptr. A frame_info_ptr is a mechanism to cache a frame-id and frame-level so that we can re-find a frame if the cache gets cleared. But having get_prev_frame_raw return a frame_info_ptr makes no sense (to me), we know at this point that the frame doesn't have a frame-id, so there is no way that the frame_info_ptr can ever do its job. Similarly for compute_frame_id, we know the frame we are passing in doesn't have a frame-id yet, so why pass it a frame_info_ptr? I wonder if we change these functions to take a raw frame_info* then we might (I haven't tried it yet) be able to have the frame_info_ptr constructor assert that the frame_info* it is holding has a valid frame_id, which we cannot right now, at least in part because of these two functions. Anyway, I just wondered if you'd seen some problem with changing these functions that I was missing? Thanks, Andrew