From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6UQMLwAEcWmqZw4AWB0awg (envelope-from ) for ; Wed, 21 Jan 2026 11:51:12 -0500 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=OkUZb2lF; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B2B2F1E08D; Wed, 21 Jan 2026 11:51:12 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,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 E791C1E08D for ; Wed, 21 Jan 2026 11:51:11 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 4FA324BC8971 for ; Wed, 21 Jan 2026 16:51:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4FA324BC8971 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=OkUZb2lF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 723244BA900C for ; Wed, 21 Jan 2026 16:50:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 723244BA900C 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 723244BA900C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769014244; cv=none; b=Xq/2R76gTo2GrHIRaz8bACfEzCm5TgcVnsq31xdj61wi5QyYajsCYjYwjza4kdqXedFbxcAEGnVpyr90UozupieU0Jr+jAjloIxx9MGYqiouk6WRIKElQbH5dcsnl9CWjSaVS+HUDkh05fa5FEJqcPYm91s/S34HYaQkhiT1odw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769014244; c=relaxed/simple; bh=Xln9e4XqXEAZShFERJLb5hadRa4jY/cnrHdL53jH3Co=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=RIAM4qRZS67juNPPbmKsuxtVKSGzlolPid1rrbcIfveH0CmiG6lzYiwIsA4+Lu4Hb7rpqyE5uJFYFiSsFyXf3oppB0s3qHTXjhtxZ9i1OsUjTcFJfe9tW/+mM6gUxtVTns4YHWACLifL6PU7NM8d+VLv3FJzqLwwHDpl3yUksQo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 723244BA900C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769014244; h=from:from:reply-to:subject:subject: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=Bnl5h0ZzrOqx7ZLBOF+qbxU1tawR7OW00qjL4yuUZoM=; b=OkUZb2lFKMH3YeJjZYnVWDd8vjS5zTx2e2YLAwPt5k3SHi99CHia1MofJ91WmKAW2O0hNn 6B8i+vi2egH556hcF6HxB2ctP9HQjCbUuNIditG5x5z6Vk4JNQ2mh/lQXYcO8borx2ooJe I+pjeqUGwaXrAQJOQHj6i7bVV8dFePM= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-501-tzgEQPboO5SS10tkAHwEHw-1; Wed, 21 Jan 2026 11:50:42 -0500 X-MC-Unique: tzgEQPboO5SS10tkAHwEHw-1 X-Mimecast-MFC-AGG-ID: tzgEQPboO5SS10tkAHwEHw_1769014242 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-42fdbba545fso1237045f8f.0 for ; Wed, 21 Jan 2026 08:50:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769014241; x=1769619041; h=content-transfer-encoding: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=FpelJvTbrN8apMAdRXYZE4O3LWi191RnGOHwybxyQco=; b=mZsBQXtY/JjANBGEos/Ipiaqe5xBeefMo2I6WI5ufUPsa5yIDiE0Yu3lJoQErJJMCv lcz4bvnp2W4o2XTIpeAWuw0Wdodr6f/IKhLpk/tbok09xLJo0uzEBnE3aXb29dDXss7s ZZfG4oRw51Gbbr8nznnSaGerpACEuHSXH4TZBPwU7EenFjJ7de+YbIlCNHk4Fd1WrlkH 7JtgjtxPRR5S0i/XWjfMfl1ST2sRTk88DsY/ELXHICQ2Z0xJNkyXkq2OWPYE0VtBj6FD GWsDeOaWHiBX2sySmWZLdAJYNwjXvHXGLqAvqmIzdtgXMC9EFqIuipTHP3rvkcYvVYUC 5VJQ== X-Forwarded-Encrypted: i=1; AJvYcCWD38O1NdTTfjIrHxyLa2FFJKT4tRb2POBCCOlwR8dYRh/R7e6yR1Z5mGaF+WThZndOqKbuCH8PqOBMrQ==@sourceware.org X-Gm-Message-State: AOJu0YxmbNhV6D+IwxifZPLlvGJ+mqRtPpjWzMwW7h31dlB9P07iEgyh w5yZOqjDth5wZhyXiRATiG3PQc5gRFyvVL3ImAnQTaVOo4WmkkxiSAgb57Tp+xXv6ZEj88HN35o 6grFXMjlG+f7cjh5h8TjBtoAHznPqh+iD09D7CrBZXAiGEqmBaZvUFhw/02dasUMhHgvbPz0= X-Gm-Gg: AZuq6aJarO9QXI2TT9xw6WlY/CbMjTml9SkCIDWMvjOZWnxULQi2fEvjJgQ5uhjbhHu WuI783zqnmm69npiTzUN/fYe8iqFznEBtvfqYGJc6Ls+MBEdl/IwLFmGuWMNV6yGgeAk5qxc6Lr xxNJZvzdV1ikBPSuutArgpRZwq4ZSqwkmivYyKI8C4Qb1KF9TrSd8aDrX6ZQpgCQ6QlekIIlbFM GhAI4HSRZbbnkbFoGHgZvupU84qBpXrzwEBQs5b0K8DjJrD955IuTCpeXF/UEQaJ9ktlzg9BswH S64VW9IsLvIE3TVPCxRhfMc/NbTZXatrwOTw6Ieaxycmfs9BOTVVBluo69smSzH9zzx6cK4f6HA AEg/T X-Received: by 2002:a05:6000:1acc:b0:430:f736:7cc with SMTP id ffacd0b85a97d-435a5f4d7a7mr122140f8f.1.1769014241263; Wed, 21 Jan 2026 08:50:41 -0800 (PST) X-Received: by 2002:a05:6000:1acc:b0:430:f736:7cc with SMTP id ffacd0b85a97d-435a5f4d7a7mr122101f8f.1.1769014240755; Wed, 21 Jan 2026 08:50:40 -0800 (PST) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4359f4a7ac7sm4753534f8f.20.2026.01.21.08.50.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 08:50:40 -0800 (PST) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x (alternative) In-Reply-To: <5e904db2-8fe3-42a3-b8ac-32255471b2b5@suse.de> References: <20251211133946.962934-1-tdevries@suse.de> <87a4y8qru0.fsf@redhat.com> <5e904db2-8fe3-42a3-b8ac-32255471b2b5@suse.de> Date: Wed, 21 Jan 2026 16:50:39 +0000 Message-ID: <871pjij4f4.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: a2pdN0AOmkZMFcRSwgqJqjN-92VkyaLi0Y6zCY_3wNA_1769014242 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Tom de Vries writes: > On 1/20/26 3:30 PM, Andrew Burgess wrote: >> Tom de Vries writes: >>=20 >>> 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 st= ack?)^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 st= ack?)^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 pro= duces the >>> frame-id for frame #5 at frame #4. Consequently, when arriving at fram= e #5, a >>> cycle is detected. >> I don't believe this is how it works. See below for what I think happen= s. >>=20 >>> [ It took me a while to understand this because of the following off-by= -one >>> confusion: for frame #0, we get pending_frame.level() =3D=3D 1. So whe= n >>> stop_at_level =3D=3D 5, the custom unwinder calculates a frame-id for f= rame #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. >>=20 >> It does appear that for frame #0 we get pending_frame.level() =3D=3D 1, = but >> this isn't what's really happening. >>=20 >> 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() =3D=3D 1. >>=20 >> The frame-id calculated within TestUnwinder.__call__ is the frame-id for >> the previous (outer, older) frame. So, when pending_frame.level() =3D= =3D 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 (=20 > https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Unwinding-Fram= es-in-Python.html=20 > ): > ... > For the frames it can sniff an unwinder provides two additional methods:= =20 > it can return frame=E2=80=99s ID, and it can fetch registers from the pre= vious=20 > frame. > > ... > > You implement a frame unwinder in Python as a class with which has two=20 > attributes, name and enabled, with obvious meanings, and a single method= =20 > __call__, which examines a given frame and returns an object (an=20 > instance of gdb.UnwindInfo class) describing it. If an unwinder does not= =20 > recognize a frame, it should return None. The code in GDB that enables=20 > writing unwinders in Python uses this object to return frame=E2=80=99s ID= and=20 > previous frame registers when GDB core asks for them. > ... > my understanding is that for pending_frame.level() =3D=3D 5, we calculate= =20 > the frame-id for frame #5. > > On x86_64-linux, indeed that's the case, the output of maint print=20 > frame-id 5 matches the sp/pc calculated for pending_frame.level() =3D=3D = 5.=20 > This is shown in more detail in the commit message of the v2 I've submitt= ed. You are 100% correct, and I feel I owe you an apology on this point. I'll take a look at v2. Thanks, Andrew