From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sCt1Azpbb2n8UwwAWB0awg (envelope-from ) for ; Tue, 20 Jan 2026 05:38:50 -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=TNe/Gr7t; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id F2E091E0AD; Tue, 20 Jan 2026 05:38:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.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,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 48FCF1E08D for ; Tue, 20 Jan 2026 05:38:49 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 971604BA9001 for ; Tue, 20 Jan 2026 10:38:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 971604BA9001 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=TNe/Gr7t 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 316044C31868 for ; Tue, 20 Jan 2026 10:38:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 316044C31868 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 316044C31868 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1768905497; cv=none; b=G6RpsmIrootEcLz+jKKLenLV8c3FfBQ38QSL+bkp/y/K9Wm1XWL3wzcCq0UPg2cuO5oTHBe+fiUp+RT5JH7XAH6+uqWd+fsoNejFb9EM69EUBYL30MIWQs8tGeAzYyfm2gTzmyqhQPpjcFFiJDISYRfQYm4TfrzVFKi1N+3/MJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1768905497; c=relaxed/simple; bh=PEoJiJALMwDW1vWgnw06FU6UKMWfMtYpQPg+nCcStZ8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ugckHTgpKd5vKJBo6+qTYDIqazJXTR5SUtacn9HH3YQLloVDdg/RHvP4rDhXl513vGEAKAa3PUVlruSPEJtWtdqydhSN8nzDsRDdamU0+fKbhD5Rti0cqc0GH7/tP5U6rhLeLcXJJ2AsMnehPEf3suOlbtm6it/XKQep4RnIfpQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 316044C31868 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768905496; 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=SY6oH9mniyiL1pRe+LQHD354TelZAS+gn/dCOhwySEk=; b=TNe/Gr7tzJv+mdiyWN2k+fhldHwJZhqiK9HoU5hsc2pe/Qv/7sglIKDXk47OJa+A0qx3ls 1QXZ8Ur1HomRIzTy8o/Zncl6ev8BxZfskQ0yjaqdZjzCpTBeFmaDiZzbtBawnG/5ewyvz1 AOrlLWZjUy8PPTs6h/08oMj8P+s9pLQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-308-CVeY5AAJMOmxtMrKCuz1Bw-1; Tue, 20 Jan 2026 05:38:15 -0500 X-MC-Unique: CVeY5AAJMOmxtMrKCuz1Bw-1 X-Mimecast-MFC-AGG-ID: CVeY5AAJMOmxtMrKCuz1Bw_1768905494 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47ee8808ffbso39408615e9.2 for ; Tue, 20 Jan 2026 02:38:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768905494; x=1769510294; 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=SY6oH9mniyiL1pRe+LQHD354TelZAS+gn/dCOhwySEk=; b=glWy2RCpuJsmUM3dbu97OhiO21WkBih9hsl+wUw9+N/T/kqhCq0ChdJdpbr5y4Xhk0 O3TS9LbHgAPCUkUT65/Vb3x8XxP7Iq5yQcuPGc+k6oKFmvwr1BOCTbA0Xbv0ORqPSUvg rkmRrSqRHG7f1nRNpEO19ZqNnIptTFIIpAK8klxyv3FkSGx8UKAlK43QCh2B/42NIZrl hBgkPz7iFAewIdWyw0+uMbE9KTHVedCuO1uhaS3x1pkiHQdcJafQH8dDOg+xQB7an0Jg DIpNQlvO4Yp9vxOjMlQoKwlE0hljHQ3My0eoxaHSny/RhYT7yVHrSFcVoFfzbS3EuFEO lsKg== X-Forwarded-Encrypted: i=1; AJvYcCWxjAVSAqjg3o2Kk4v2icbRwweLEuvRLfU1lth6LkKg+YM8HfqlZFPnoHSYrAlgzYv4u2YUiaLK59EHig==@sourceware.org X-Gm-Message-State: AOJu0Yxuv6ORDfS4nas8ouZ4Oz14FXg+Z014L2ZdhCU9qzTMI1+gIgeY SlEjUm3AsGXis/f1zqCLILtVXaxMH/jOiafIiQqTQETNTJrBjv2Aq6sNLjB7UBPoQXOut/3keP+ 2pUfc7X++mWKX9gpEsyO5KEu3ez4mqhg/MgVXSukOZ4lcZSnXY++Bfpgn4VFEJ76KUvab7v4= X-Gm-Gg: AY/fxX6T0tVrSeUI9rHGuff5kLesudGQPUzim7Ka4H88Ug1p1GubPFhw0QitvRI2Lwt 05LEzKd1EdNirHr15BuE4wUwWvKDuifxXnK25Dh6q/8HL/bwOAK06JPPqD39eTBHfyyhzm44vCJ AARtYyRt3uubjknQW7nTV1LxS8K5KqnmyomJHKA/UjaWJlw9FSLBQZF3v8ShtJy8culVY7vafbd +2xcBnUQU5sJ3Jh4Etdumq8FHgOj5Dja9WqjM/Lyf78W02lz+qLrSwgTwAeYj4mUxkap1s8VwT2 XL4XDHiFiFc4UgF/0G5tv+Hei9iLLwEo1XeBmthq5ezfHIUXPwLd98VBv9r7mGuZrVJjU2vssvs f+oyefFwI4Kqc0eFd4ObH1B9Rj+Z9 X-Received: by 2002:a05:600c:8b55:b0:477:9f34:17b8 with SMTP id 5b1f17b1804b1-4801e2fbd61mr186379515e9.1.1768905493626; Tue, 20 Jan 2026 02:38:13 -0800 (PST) X-Received: by 2002:a05:600c:8b55:b0:477:9f34:17b8 with SMTP id 5b1f17b1804b1-4801e2fbd61mr186379205e9.1.1768905493180; Tue, 20 Jan 2026 02:38:13 -0800 (PST) Received: from localhost (13.81.93.209.dyn.plus.net. [209.93.81.13]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e9fb193sm101096345e9.6.2026.01.20.02.38.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 02:38:12 -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: <20251211133946.962934-1-tdevries@suse.de> References: <20251211133946.962934-1-tdevries@suse.de> Date: Tue, 20 Jan 2026 10:38:11 +0000 Message-ID: <87cy34r2lo.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Zrz-uUdTMFC3eakLmdKUs8KzlMiA1JK9MOHqso1h9pA_1768905494 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 Thanks for looking into this. I have a few comments... 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. > > [ 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'm going to need to think about this some more, as still don't understand this description of the problem. For now I'm assuming this is all correct, so I have a few comments on the changes below ... > > This relies on the test-case to calculate the offending frame-id, and the > problem on s390x is that that calculation is incorrect. > > Fix this by using "maint print frame-id" to get all frame-ids, and using those > instead. > > Tested on x86_64-linux and s390x-linux. > --- > .../gdb.base/inline-frame-cycle-unwind.exp | 13 +++++++++++++ > gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py | 8 +++++--- > 2 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp > index 7fc47af624f..5c6504323ee 100644 > --- a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp > +++ b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp > @@ -72,6 +72,19 @@ gdb_continue_to_breakpoint "stop at test breakpoint" > gdb_test_no_output "source ${pyfile}"\ > "import python scripts" > > +foreach_with_prefix n { 0 1 2 3 4 5 6 } { > + set sp 0x0 > + set pc 0x0 Are these set to 0 needed? We don't try to use these unless we match the regexp, in which case they'll be set to the values that are matched, right? > + gdb_test_multiple "maint print frame-id $n" "" { > + -re -wrap "frame-id for frame #$n: {stack=($hex),code=($hex),.*}" { > + set sp $expect_out(1,string) > + set pc $expect_out(2,string) > + gdb_test_no_output "python frame_id_sp.append($sp)" > + gdb_test_no_output "python frame_id_pc.append($pc)" > + } > + } > +} > + > # Test with and without filters. > foreach bt_cmd { "bt" "bt -no-filters" } { > with_test_prefix "$bt_cmd" { > diff --git a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py > index 55dea989512..25a67b1a7c9 100644 > --- a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py > +++ b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py > @@ -26,6 +26,9 @@ stop_at_level = None > # function called recursively. > stack_adjust = None I think you should delete STACK_ADJUST, and the code at the end of this file that sets it up. The comment at the end of the file which describes what the setup code (at the end of the file) is doing should probably then be moved to the start of the file, and ideally extended to explain that frame_id_sp and frame_id_pc need to be filled in by the .exp script in order for the test to work correctly. The use of STACK_ADJUST within TestUnwinder.__call__ can then be removed, by maybe replace it with a check, something like: if len(frame_id_sp) < stop_at_level or len(frame_id_pc) < stop_at_level: raise gdb.GdbError("invalid stack_adjust") Thanks, Andrew > > +frame_id_sp = [] > +frame_id_pc = [] > + > > class FrameId(object): > def __init__(self, sp, pc): > @@ -55,9 +58,8 @@ class TestUnwinder(Unwinder): > if stop_at_level not in [1, 3, 5]: > raise gdb.GdbError("invalid stop_at_level") > > - sp_desc = pending_frame.architecture().registers().find("sp") > - sp = pending_frame.read_register(sp_desc) + stack_adjust > - pc = (gdb.lookup_symbol("normal_func"))[0].value().address > + sp = frame_id_sp[stop_at_level] > + pc = frame_id_pc[stop_at_level] > unwinder = pending_frame.create_unwind_info(FrameId(sp, pc)) > > for reg in pending_frame.architecture().registers("general"): > > base-commit: 2271dee682787051c0628c869d7cdb220bdd0e67 > -- > 2.51.0