From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gTh2K8l3fGpXmCAAWB0awg (envelope-from ) for ; Wed, 12 Aug 2026 09:40:25 -0400 Received: by simark.ca (Postfix, from userid 112) id ADDEF1E033; Wed, 12 Aug 2026 09:40:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 7EB641E033 for ; Wed, 12 Aug 2026 09:40:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 238444BB24DF for ; Wed, 12 Aug 2026 13:40:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 238444BB24DF Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id C9CA84BAE7E9 for ; Wed, 12 Aug 2026 13:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9CA84BAE7E9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C9CA84BAE7E9 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=78.133.224.34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786542001; cv=none; b=t6YcNZtfGoNieBtIHo6MYHKz0ZOLD1T4tof+CDESsgXFza9gh1YqJLPxaZDpUvsZG3XuXFn6NIhIWbnXUFKo/T/ZXpg6k3S59WBz5+lvgp4MnrHU9V0uyqFPj/uBdu/JsBDXMLEHUWw3wPJogOg8l5BXx/mq5jz6mo+Oc7NuFn8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786542001; c=relaxed/simple; bh=jWcGTTxoz6RE+47fsL6ivAS7ssJEgFJD33qNUC61tSo=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=XLmDlWdzKERrUlXk0nWq/voiqIDMYcuohSIhTlRsDtggzTkJGydMkft8ATmWoE6Ppad1/0cJntGEh0r2wntxHAFX+V0ZBzbfWRQnxEHKpC420u24NIyrJEJSUBdmhOTLnoybieVWxPEbhKGf2gkv41vpq3vZGiGXIsObM15F3VY= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C9CA84BAE7E9 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 3D7FB92009C; Wed, 12 Aug 2026 15:40:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 374F492009B; Wed, 12 Aug 2026 14:40:00 +0100 (BST) Date: Wed, 12 Aug 2026 14:40:00 +0100 (BST) From: "Maciej W. Rozycki" To: Orgad Shaneh cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/mips: unwind past post-prologue SP adjustments in syscall stubs In-Reply-To: <20260806180912.7143-1-orgads@gmail.com> Message-ID: References: <20260806180912.7143-1-orgads@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 On Thu, 6 Aug 2026, Orgad Shaneh wrote: > When computing a frame (not when skipping the prologue), continue > scanning from where the prologue-end heuristic stopped up to the PC, > accumulating any further SP adjustments. Branches are deliberately > not followed: compilers do not move SP mid-function outside prologue > and epilogue (alloca frames use a frame pointer and are excluded), so > post-prologue adjustments occur in practice only around syscall > instructions in libc stubs, where paired temporary adjustments that > were fully crossed cancel out in a linear scan. The scan does stop at > a "jr $ra", though: past one, the range crosses a complete alternate > return path - e.g. the single-thread fast path of glibc's cancellable > syscall wrappers, which returns before the multithreaded path saves RA > and runs the syscall - and a linear sum of the remainder is no longer > meaningful, so the frame is left unchanged. If the net result is > positive, rescan with the entry SP moved accordingly - the same > restart mechanism already used for alloca - so that both the frame > base and the register save slots are computed against the true frame. I'm inconvinced, the heuristic unwinders are specifically for prologues and not random stuff within function bodies. Have you considered asking the relevant project maintainers to add the missing CFI records? That would be the proper way to handle the situation. Indeed there've been voices asking to drop the heuristic unwinders from GDB altogether. Thank you for your submission regardless. Maciej