From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qaAOMJ5lOmrevxQAWB0awg (envelope-from ) for ; Tue, 23 Jun 2026 06:53: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=hVvBO8u+; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C14C51E024; Tue, 23 Jun 2026 06:53: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=unavailable 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 4F5281E024 for ; Tue, 23 Jun 2026 06:53:18 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 214DC4BA2E0D for ; Tue, 23 Jun 2026 10:53:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 214DC4BA2E0D 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=hVvBO8u+ 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 70C6B4BA5434 for ; Tue, 23 Jun 2026 10:52:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 70C6B4BA5434 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 70C6B4BA5434 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=1782211973; cv=none; b=Ji3QRwfFux+DG4RkTXaEZsLnVlFC7TyqkFrwJanHqSsC52WwQQK2rG6AbOPI40OmIvBaOS39uTvFxpWdXVndPc9flKXYREHJtWKdJjLyHZ4niJ5x1VlG8lwFUz96bTVT/qI9Alb4smaSxERPT3dwmLnz6wwnGUdpKOF5myofS3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782211973; c=relaxed/simple; bh=3g5aRzEMS6vvghVlysX8LdGQfjDujzZKrFcERqR1qCM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Hw8y0JJItvkiO2kLJcdapHdc0c4cOEy2vusAP+y7lrsXw7lWv2sOQlMNHGWyrvSVmnjCFY5VGVgaSSNYZDQQM3J2OjahA4Pt54+2M2/LOmJit+es4d1ICHIlw1sLlGmFm9KCgeMIcoKLrsMHo4AQAlgEPdgyJ2mt6+vk285h9K4= 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=hVvBO8u+ DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70C6B4BA5434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782211973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NaEwHmvBUrQDTtOrvbPNKIHNi5TqMxBCICEmx/MMMG4=; b=hVvBO8u+P0z8iEGLtVtY0cV4UTNuTa2nfD3ckDocnSuCTKA8zrxt3uYaDY3GgmmRwsw4Hz ZStT16oEB6sSKos7Ktp6QdfdG/57HE+z4+QgfHYEBfuCGkRNdcdslxteX2/a6xOm3YrVDb hYfyUHNjTOqubP9Xm3jdt9GvZ0fen8o= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-294-w91YUe6fOaeU5D48hJCnGA-1; Tue, 23 Jun 2026 06:52:50 -0400 X-MC-Unique: w91YUe6fOaeU5D48hJCnGA-1 X-Mimecast-MFC-AGG-ID: w91YUe6fOaeU5D48hJCnGA_1782211969 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-45ef616db45so4359416f8f.2 for ; Tue, 23 Jun 2026 03:52:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782211969; x=1782816769; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NaEwHmvBUrQDTtOrvbPNKIHNi5TqMxBCICEmx/MMMG4=; b=TbvGDEqBDN+E0jcio3sgJus5kxMGUfVfXUNXURb5AzBfOWGRF5dT6LaUxkVIBtHEQ7 WQL7kg8clkACwCd+TD+k6i8IACGHwfDtCeRV06Wj36O47S4e6pjdXSOeOgzAxAzEbUjj L0o6DPasQTx/rap5aZRDRIOXvZl/L+9ZpaEappoVXbLQeYx06RGdgOtZoC7BIa0UvWpq QxYOjYBmldnGPzBBx1oxaxwXxttXmP4DnyeAf0DZ9OdNGUZRqo0SXswNXGCUe157/Qnp 49NdgGRvCc7RZEW0MYTjpazpv/zamKDLUuBcpfvTj352pW/al6X8PNp+7jDldl+QRsmR QBWQ== X-Forwarded-Encrypted: i=1; AHgh+RpN786Iq3JLoX3h8DrxSy89X8TP2fjMxRyqLPTxaogpCO0YBpUnI8FJQx+ddFiHGXgW/4vnzL8bGygPcQ==@sourceware.org X-Gm-Message-State: AOJu0YyY+hjIdvnYmW2Tyx13aNY4MNDDpkpbTciH1d1UA9P/nCbtI6sd CsbqIDKYYo3pCVmbgHEmoTb89lYM+PzViB+8TJek5xdQHr6XTBnlDemC5KPnn6rhnRfSI6fSFTW GgOBwSCxZDQPGs3bx+2ptsqqXuKnePgDPTB0HhDoCZ99jDFlRpmD3TINSgjVbnXP18sAbmqo= X-Gm-Gg: AfdE7ckmXe0cPYoTH2lMCfbZ4IT4gLZ/6ZmDlgrmx1nayA8ToIZnmxSL7nwLn+7HoVp OouR+jQ4ltDdv/ExzYvD2nfxV9hBm42tcmWyRQzo0JNSUQ2LnvSdFqXH2FUfrLR4XHTqNbp35gu AXKzxen+rU0kQ24+IyXxi7fYEGz6u+9R0q/bME6SdNy1ZT/GUKz8sP12Zu3bPHr+h/t0v4nm98q UiFBQQ+UbXcR8YRa2RZ+yujKc6jgOouFvGELqhz9cFnLRBg3/Bhd5LjS9b9+0kU8ERkezskjDDL SzcdvYz3ZrOsGXhAHFnVvIOLRA9fUNUC8zcGPEkc4cukZaq6EtCVXqHXrcJwjhKY9Hb9vDFFpc+ yTnwo1TYzfIO92TsQJBhWwq3kVyNhow== X-Received: by 2002:a05:6000:40ca:b0:460:1e5a:2267 with SMTP id ffacd0b85a97d-46adb49139cmr3572573f8f.17.1782211968835; Tue, 23 Jun 2026 03:52:48 -0700 (PDT) X-Received: by 2002:a05:6000:40ca:b0:460:1e5a:2267 with SMTP id ffacd0b85a97d-46adb49139cmr3572531f8f.17.1782211968378; Tue, 23 Jun 2026 03:52:48 -0700 (PDT) Received: from localhost (19.81.93.209.dyn.plus.net. [209.93.81.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-466643f4d9csm34081316f8f.4.2026.06.23.03.52.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 03:52:48 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCHv2 1/2] gdb: remove sentinel frame check in frame_find_by_id In-Reply-To: References: Date: Tue, 23 Jun 2026 11:52:47 +0100 Message-ID: <87tsqto7eo.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: VxxDSNrJTAY266edF98qtGO8nVulQgK_JU4EyibZyZo_1782211969 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 Simon Marchi writes: > On 6/22/26 5:33 PM, Andrew Burgess wrote: >> While reviewing another patch Simon pointed out that the code in >> frame_find_by_id for looking up the sentinel frame is no longer needed >> since commit: >> >> commit 19f988359a62889b00d67fb59ef8c7d6d759fc98 >> Date: Mon Jan 30 15:02:49 2023 -0500 >> >> gdb: give sentinel for user frames distinct IDs, register sentinel frames to the frame cache >> >> Prior to this commit the sentinel_frame was not added to the frame >> stash, so we needed a manual check to lookup the sentinel frame. >> After this commit the sentinel frame is added to the stash so the >> manual check, though perfectly valid, is just unnecessary complexity, >> and can be removed. A frame stash lookup is just a hash lookup, and >> is relatively cheap, so switching to this isn't much extra cost. >> >> While I was working in frame_find_by_id I made a couple of additional >> changes: >> >> 1. I moved the declarations of frame and prev_frame locals into the >> function body, closer to where they are first defined. >> >> 2. Instead of treating a frame_info_ptr as a bool, I made use of the >> frame_info_ptr::is_null method. >> >> There should be no user visible changes after this commit. >> --- >> gdb/frame.c | 13 ++++--------- >> 1 file changed, 4 insertions(+), 9 deletions(-) >> >> diff --git a/gdb/frame.c b/gdb/frame.c >> index f64f5554f8c..c1a7c41dc4a 100644 >> --- a/gdb/frame.c >> +++ b/gdb/frame.c >> @@ -959,17 +959,11 @@ frame_id_inner (struct gdbarch *gdbarch, struct frame_id l, struct frame_id r) >> frame_info_ptr >> frame_find_by_id (struct frame_id id) >> { >> - frame_info_ptr frame, prev_frame; >> - >> /* ZERO denotes the null frame, let the caller decide what to do >> about it. Should it instead return get_current_frame()? */ >> if (!frame_id_p (id)) >> return NULL; >> >> - /* Check for the sentinel frame. */ >> - if (id == frame_id_build_sentinel (0, 0)) >> - return frame_info_ptr (sentinel_frame); > > From what you know, was this check even working today? This compares > the id we're looking for (which presumably has "real" addresses) with > "code" and "special" addresses set to 0. Yes it was working. In get_current_frame, where we build the actual stack based on the current register state, the sentinel frame is created with addresses 0 and 0 for stack and code. It's only for the case of user created frames, where the user provides a stack and code address (in create_new_frame) that we create a sentinel frame with actual, real addresses. So in the first case the above check would find the sentinel frame, but in the second we relied on the cache. I don't see any reason why these two cases need to be handled differently. Maybe there's a tiny performance improvement from the hard coded check, but unless someone complains I think just handling both cases via the frame cache makes more sense. Thanks, Andrew > > In any case, LGTM. > > Approved-By: Simon Marchi > > Simon