From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PWolBr8IcWm/bQ4AWB0awg (envelope-from ) for ; Wed, 21 Jan 2026 12:11:27 -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=NEAcm/CI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0C4BD1E0AD; Wed, 21 Jan 2026 12:11:27 -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 5D5EB1E08D for ; Wed, 21 Jan 2026 12:11:26 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id BAEDE4BC896F for ; Wed, 21 Jan 2026 17:11:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BAEDE4BC896F 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=NEAcm/CI 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 19A294BC0568 for ; Wed, 21 Jan 2026 17:10:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 19A294BC0568 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 19A294BC0568 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=1769015459; cv=none; b=CREEjyxE6Gjzw5mvXVYODlYIyxGYWlVr378O4pWwWGTT1I2OAaGWu7ZNWyTrP3kZ3lhTMeqU4/W8eoxFg51j8v6ZrL7OO2XG2zUO4qBSxqx0geBNx+VEgZKnUuUzllkPVIL3YaEMCGrfo080N2VSFmO/Q3W3Ow9EoSvXGHkUEGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769015459; c=relaxed/simple; bh=sUXZUEKgrIcCofNGbSqwB5b0OkUwHbUcRRcON2ZtYmA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HvK4LVZryxUTAdDE7x004nIgjZ3UXNRCY+pl5REMw78sxQ2oYRDD/4vMejo6GRReX2PDZazI2cmpJTLCddUM4i2Y3CM0x59wCu44Xo8MUF+P3CCyLcz21v/Ih9gPh3qtmv9I+MtZeGD2W6S0qvmMCeHZxCv/hlWVtCZmYqsdlfY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 19A294BC0568 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769015458; 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=wWvIvw9Wq0N6/J5vfvbg12gyJw2KjkYu387djrD902I=; b=NEAcm/CIHL98JZ5SOCxyH+BNocC4av+fvCCHMeO+sgG5iywoXRavM486WCldYdyOWL3vcB HEKUWXeJHctr9d7bn44b1Gv6KusB9ncwzgdb4Rm+EGIWP5+UycErSl9D6qgakuEo+cpjR6 Ane8PybFM9/d9I5FQQJx3GD4ods2psQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-425-x5I1sI75P1-WN6-NJzoOaQ-1; Wed, 21 Jan 2026 12:10:57 -0500 X-MC-Unique: x5I1sI75P1-WN6-NJzoOaQ-1 X-Mimecast-MFC-AGG-ID: x5I1sI75P1-WN6-NJzoOaQ_1769015456 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-47d3c9b8c56so2136045e9.0 for ; Wed, 21 Jan 2026 09:10:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769015456; x=1769620256; 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=wWvIvw9Wq0N6/J5vfvbg12gyJw2KjkYu387djrD902I=; b=Lr99QPmc54GE6CvVg9rQFr2BsIWzHvSOA4zUVUIQUt/wiUVaOPjoC5XsMofhwelolQ u3PbPNoXS81lugEO2gE/6khNzJ3Ol+1QjlGscWY7pM5FE/7mdwo+OkVmIb4hz0cKHnoH U0OEQThjC18yEBhFT4GWswBkf7lzDgRJGmGfL58nMuxNmaNNPneW7oHAjlSLVp2fpzx2 1J3qQmeA/DBBdRbsqC7Qexx6/xDT0TaSqFjIqMnJVZVBeyLH1eK++gpGoq9uziwI4jli AgrAtk6iQiJmw31e4f9LClMV2i3L1mZenbyfWUgPGh+9ZFZnLj2rQfutoq9pPmi5xuSJ l88w== X-Forwarded-Encrypted: i=1; AJvYcCW03oFsjmvsGfMgudFq8pcFKCT8CYhhOztbQK8eOTuZ9irtivXl3rNZa/ICGsdEtn1YBV1DN/K+HTRHWw==@sourceware.org X-Gm-Message-State: AOJu0YzRJYCpjNMjNYwhsYMHqzJ4ixMZkdn17NVNLua5zrd6eIm3BgPM bmJeLWZzJF1DT4/rOP5xajszsoC4CjbCzbcYM2ZFmlJ+Zgn6Twr6PF1cmXRmrGmKII2ZYYh8zZQ +yU4IV3/Et0p0SsM5XPjbVM1L3PwjZHS//yLS6ENFHxMB50UjqcE02eEqo7CtfyY= X-Gm-Gg: AZuq6aLKAeKLq+OpKcYgW+geYbZz24Dt3T0f+1g0PLmChPEuPcHCbskzfg0lLU7L13/ U3hTApPNmJ14kNkiFIaexcz3MFokvZj6MeTXphd0FukV3rN832wKeTCbwMdWx9gV9VI2sRcX+j9 R3VLADirM443wsuhKym2ijTPiHDC8z6R8dK/U5Gzxjx7xz6oMRT0jTfuNZN80KPhnq567Rxg4ce +qp6qhs0UdqDwNvaFvZISkEBPJ3B2bbZpAwhxZ5fPtrthwSvU4S5n81MRf1inbPh9WBzjfsoNKw 7iGbld67yH0Z0kVIA/qH8CApJjAoXgvI7sfwJUBC8Idrr0jb/3ZBAQnv39EIIHltUTYDxqF2kdr EcVgj X-Received: by 2002:a05:600c:4449:b0:477:abea:9023 with SMTP id 5b1f17b1804b1-4801eabdecfmr223759545e9.9.1769015456019; Wed, 21 Jan 2026 09:10:56 -0800 (PST) X-Received: by 2002:a05:600c:4449:b0:477:abea:9023 with SMTP id 5b1f17b1804b1-4801eabdecfmr223758895e9.9.1769015455434; Wed, 21 Jan 2026 09:10:55 -0800 (PST) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804705b29dsm2377635e9.10.2026.01.21.09.10.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 09:10:55 -0800 (PST) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH v2] [gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x (alternative) In-Reply-To: <20260121122543.4129049-1-tdevries@suse.de> References: <20260121122543.4129049-1-tdevries@suse.de> Date: Wed, 21 Jan 2026 17:10:54 +0000 Message-ID: <87y0lqhowx.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: HuGAy2-ewteBnCLB9EK746Hgxw92Pxcyc7kCDpvbyqc_1769015456 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 Tom de Vries writes: > From: Andrew Burgess > > With test-case gdb.base/inline-frame-cycle-unwind.exp on s390x-linux, I run > into: > ... > (gdb) bt > #0 inline_func () at inline-frame-cycle-unwind.c:49 > #1 normal_func () at inline-frame-cycle-unwind.c:32 > #2 0x000000000100065c in inline_func () at inline-frame-cycle-unwind.c:45 > #3 normal_func () at inline-frame-cycle-unwind.c:32 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (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 > #0 inline_func () at inline-frame-cycle-unwind.c:49 > #1 normal_func () at inline-frame-cycle-unwind.c:32 > #2 0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45 > #3 normal_func () at inline-frame-cycle-unwind.c:32 > #4 0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45 > #5 normal_func () at inline-frame-cycle-unwind.c:32 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) PASS: $exp: bt: cycle at level 5: backtrace when the unwind is broken \ > at frame 5 > ... > > Let's first see what happens on x86_64-linux. > > The test-case installs a custom unwinder, which gets triggered with > pending_frame.level() == 5. > > The responsibility of the unwinder at that point is to: > - calculate a frame ID for the pending frame, and > - provided the register values for the previous frame (with level > pending_frame.level() + 1), as saved in the pending frame. > > However, the custom unwinder does some else. While it does calculate the > frame ID for the pending frame, instead it provides the register values for > the pending frame, which causes the unwinder to stop. Sort of. Passing a value from #n to #(n+1) unmodified isn't itself wrong, or bad, it's just saying that a register hasn't changed between frames. In this case, by passing $sp and $pc up the stack unmodified, frame #(n+1) is going to appear to be an exact duplicate of frame #n, but the custom unwinder isn't going to trigger from #(n+1), so the standard DWARF unwinder will kick in instead. The DWARF unwinder should then compute the exact same frame-id that our custom unwinder installed for frame #n, which will trigger the frame cycle which is at the core of this test. > > After adding some debugging prints, we can see that the frame ID calculated by > the custom unwinder: > ... > LEVEL: 5 > FrameID: sp: 7fffffffcd50, pc: 401116 > ... > matches the frame ID as calculated by GDB: > ... > (gdb) maint print frame-id 5 > frame-id for frame #5: {stack=0x7fffffffcd50,code=0x0000000000401116,!special} > ... > > Now back to s390x-linux. > > This time, the frame ID calculated by the custom unwinder: > ... > LEVEL: 5 > FrameID: sp: 3ffffffe8d0, pc: 1000608 > ... > does not match the frame ID as calculated by GDB: > ... > (gdb) maint print frame-id 5 > frame-id for frame #5: {stack=0x3ffffffe970,code=0x0000000001000608,!special} > ... > > Instead, it matches the frame ID for frame #3: > ... > (gdb) maint print frame-id 3 > frame-id for frame #3: {stack=0x3ffffffe8d0,code=0x0000000001000608,!special} > ... So the problem for s390 is the difference in relationship between the Call Frame Address (CFA), as used in the frame-id, and $sp value for a function. On x86-64, for this specific test, the difference between $sp and the CFA for frames 1, 3, and 5 is the same as the difference between $sp values between these frames. There's no reason why this has to be the case, it just is, and the original form of this test depended on this fact. Remember, our custom unwinder, when triggered for frame #n, wants to generate the actual, real, correct, frame-id for frame #n. But when the test was written 'maint print frame-id' wasn't a thing, so the hack that I used to calculate the frame-id noticed that the $sp to CFA for a frame was the same as $sp to $sp between frames. So I calculate the difference between $sp values (called STACK_ADJUST), and then add this to the $sp value in frame #n to try and recreate the frame-id. On s390 however, my hack doesn't work. The CFA for a frame is 2x the frame size (on this test, on the machine and compiler I tested with). And so, when we try to create the frame-id for #n in the custom unwinder, instead of calculating the correct CFA, we calculate a different frame-id that happens to be the same as an earlier frame, and that is why the frame is truncated where it is. > > Fix this by using "maint print frame-id" to get all frame-ids, and using those > instead. I did make an attempt at fixing this, but having read your commit message, and having written the above reply, I think your approach here is probably the right one. It might be worth folding some of the above text into the commit message though, what do you think? I'm happy to do this if you'd like me too. Thanks, Andrew