From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZL8XBqnVcGmnLQ4AWB0awg (envelope-from ) for ; Wed, 21 Jan 2026 08:33:29 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=w5O1664p; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=fEGF7F3W; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=w5O1664p; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=fEGF7F3W; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 073441E0AD; Wed, 21 Jan 2026 08:33:29 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED 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 E4B761E08D for ; Wed, 21 Jan 2026 08:33:27 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 3A9F34BA9023 for ; Wed, 21 Jan 2026 13:33:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3A9F34BA9023 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=w5O1664p; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=fEGF7F3W; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=w5O1664p; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=fEGF7F3W Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 46E464BA900E for ; Wed, 21 Jan 2026 13:32:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 46E464BA900E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 46E464BA900E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769002339; cv=none; b=NiTxH60cptWPnJle7JD6Dke+mglFc1d/rsuQDcq4PQfcP9dAvFJcIEJ2tn1ss7J9TOd9T8gJE1hc0N2+qETfAqPAzmBo7UX7m4I/ariQAPKHqKnmaQ0bRgTKgjWDeZdfAi7z3rPykdMM9zUtEMCEEI4kdc2Muy8QMerLhBGiROY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769002339; c=relaxed/simple; bh=D7Mn4upbM+WFeCs1wD6cTnPpM+IVLb1vr2vgaAYWY7I=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=tDT3AkFhvLu7Vyb4hxVCBuqeQZdYTU93doGCDEKtDir/dtcfBXdi/ko/+KG+ojRkg3N3gnn6/tF8IMEua7ilcwWqmvLtO0+dgzq3dSy8uV7m5ZSpkuO2RSvrZe7HkRDEmUVNWFo/cBJAKrNrZFG7/DMDN7eG+Gym8Vsug0KQpk4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46E464BA900E Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 377C55BD14; Wed, 21 Jan 2026 13:32:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1769002338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUQjgzkj1Puu/VCfq0CfA2Iq4X7kAsAhUxneAOf07aU=; b=w5O1664pL9So9B0rnUE+C6J0EldMjSuAacT8TCUUhSNWs6EwGlyfrfyfDf8TO5IWVJu3fW dHfLL6jZj1JjMUByKVVNGp73Cft7MTIiZNG5hCNKIEXdjz2poeTe4rIlpYBrujbQ1qPwtv Rr7xVToWvDP5ZQAJbd4fNMcRk8aUUeg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1769002338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUQjgzkj1Puu/VCfq0CfA2Iq4X7kAsAhUxneAOf07aU=; b=fEGF7F3WelE4NAJCoXrKjrM4NfU24CcE2a6SaGjUngIYfIldwprrsgAPoPmfYAbsQsbOsM xAoo4V77mf4U3gAA== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1769002338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUQjgzkj1Puu/VCfq0CfA2Iq4X7kAsAhUxneAOf07aU=; b=w5O1664pL9So9B0rnUE+C6J0EldMjSuAacT8TCUUhSNWs6EwGlyfrfyfDf8TO5IWVJu3fW dHfLL6jZj1JjMUByKVVNGp73Cft7MTIiZNG5hCNKIEXdjz2poeTe4rIlpYBrujbQ1qPwtv Rr7xVToWvDP5ZQAJbd4fNMcRk8aUUeg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1769002338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUQjgzkj1Puu/VCfq0CfA2Iq4X7kAsAhUxneAOf07aU=; b=fEGF7F3WelE4NAJCoXrKjrM4NfU24CcE2a6SaGjUngIYfIldwprrsgAPoPmfYAbsQsbOsM xAoo4V77mf4U3gAA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 21AD63EA63; Wed, 21 Jan 2026 13:32:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id kjcEB2LVcGkSMgAAD6G6ig (envelope-from ); Wed, 21 Jan 2026 13:32:18 +0000 Message-ID: <5e904db2-8fe3-42a3-b8ac-32255471b2b5@suse.de> Date: Wed, 21 Jan 2026 14:32:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x (alternative) To: Andrew Burgess , gdb-patches@sourceware.org References: <20251211133946.962934-1-tdevries@suse.de> <87a4y8qru0.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: <87a4y8qru0.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid, suse.de:email, imap1.dmz-prg2.suse.org:helo] 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 1/20/26 3:30 PM, Andrew Burgess wrote: > Tom de Vries writes: > >> With test-case gdb.base/inline-frame-cycle-unwind.exp on s390x-linux, I run >> into: >> ... >> (gdb) bt^M >> #0 inline_func () at inline-frame-cycle-unwind.c:49^M >> #1 normal_func () at inline-frame-cycle-unwind.c:32^M >> #2 0x000000000100065c in inline_func () at inline-frame-cycle-unwind.c:45^M >> #3 normal_func () at inline-frame-cycle-unwind.c:32^M >> Backtrace stopped: previous frame identical to this frame (corrupt stack?)^M >> (gdb) FAIL: $exp: bt: cycle at level 5: backtrace when the unwind is broken \ >> at frame 5 >> ... >> >> In contrast, on x86_64-linux, I get: >> ... >> (gdb) bt^M >> #0 inline_func () at inline-frame-cycle-unwind.c:49^M >> #1 normal_func () at inline-frame-cycle-unwind.c:32^M >> #2 0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45^M >> #3 normal_func () at inline-frame-cycle-unwind.c:32^M >> #4 0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45^M >> #5 normal_func () at inline-frame-cycle-unwind.c:32^M >> Backtrace stopped: previous frame identical to this frame (corrupt stack?)^M >> (gdb) PASS: $exp: bt: cycle at level 5: backtrace when the unwind is broken \ >> at frame 5 >> ... >> >> AFAIU, the mechanism of the test is as follows: the custom unwinder produces the >> frame-id for frame #5 at frame #4. Consequently, when arriving at frame #5, a >> cycle is detected. > I don't believe this is how it works. See below for what I think happens. > >> [ It took me a while to understand this because of the following off-by-one >> confusion: for frame #0, we get pending_frame.level() == 1. So when >> stop_at_level == 5, the custom unwinder calculates a frame-id for frame #4, >> not frame #5. But the frame-id it calculates is the one for frame #5, so >> unwinding will stop at frame #5 because the frame-ids for frame #4 and >> frame #5 are identical. ] > I went back and looked at the unpatched test again, and I don't believe > this "off-by-one" issue is a thing, at least, I don't see one based on > your description. > > It does appear that for frame #0 we get pending_frame.level() == 1, but > this isn't what's really happening. > > Frame #0 is inline, so the Python frame unwinder is never run for this > frame. The first frame for which the Python frame unwinder is run is > frame #1, hence pending_frame.level() == 1. > > The frame-id calculated within TestUnwinder.__call__ is the frame-id for > the previous (outer, older) frame. So, when pending_frame.level() == 5 > we are calculating the frame-id for frame #6. As frame #6 then appears > to be identical to frame #5, a cycle is detected and the backtrace ends. After reading the documentation ( https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Unwinding-Frames-in-Python.html ): ... For the frames it can sniff an unwinder provides two additional methods: it can return frame’s ID, and it can fetch registers from the previous frame. ... You implement a frame unwinder in Python as a class with which has two attributes, name and enabled, with obvious meanings, and a single method __call__, which examines a given frame and returns an object (an instance of gdb.UnwindInfo class) describing it. If an unwinder does not recognize a frame, it should return None. The code in GDB that enables writing unwinders in Python uses this object to return frame’s ID and previous frame registers when GDB core asks for them. ... my understanding is that for pending_frame.level() == 5, we calculate the frame-id for frame #5. On x86_64-linux, indeed that's the case, the output of maint print frame-id 5 matches the sp/pc calculated for pending_frame.level() == 5. This is shown in more detail in the commit message of the v2 I've submitted. Thanks, - Tom