Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Tom de Vries <tdevries@suse.de>, Andrew Burgess <aburgess@redhat.com>
Subject: Re: [PATCH v2] [gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x (alternative)
Date: Sat, 24 Jan 2026 16:52:33 -0700	[thread overview]
Message-ID: <20260124165233.7dabaf09@f42-mesa-1> (raw)
In-Reply-To: <20260121122543.4129049-1-tdevries@suse.de>

Tom, Andrew,

FWIW, I'm fine with the approach taken here.  I prefer it over my
attempt to fix these failures for s390x.

Regarding the commit log - I'd like to see it written up in a way
where all of the context is supplied, including a description of the
problem being solved.  (I see that Andrew has offered to work on
the commit log and that Tom has accepted - that'd be great, IMO.)

Kevin

On Wed, 21 Jan 2026 13:25:43 +0100
Tom de Vries <tdevries@suse.de> wrote:

> From: Andrew Burgess <aburgess@redhat.com>
> 
> 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.
> 
> 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} ...
> 
> 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.
> 
> Co-Authored-By: Tom de Vries <tdevries@suse.de>
> ---
>  .../gdb.base/inline-frame-cycle-unwind.exp    |  3 +
>  .../gdb.base/inline-frame-cycle-unwind.py     | 58 +++++++++++++------
>  2 files changed, 43 insertions(+), 18 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp
> b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp index
> cc9585ee325..fd9cba78f9a 100644 ---
> a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp +++
> b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.exp @@ -72,6 +72,9 @@
> gdb_continue_to_breakpoint "stop at test breakpoint" gdb_test_no_output
> "source ${pyfile}"\ "import python scripts"
>  
> +# Print the captured frame IDs.
> +gdb_test "python print_frame_ids()"
> +
>  # 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
> 80cfb864f21..09ddfb7e536 100644 ---
> a/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py +++
> b/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.py @@ -13,6 +13,8 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>  
> +import re
> +
>  import gdb
>  from gdb.unwinder import Unwinder
>  
> @@ -21,10 +23,14 @@ from gdb.unwinder import Unwinder
>  # was written for.
>  stop_at_level = None
>  
> -# Set this to the stack frame size of frames 1, 3, and 5.  These
> -# frames will all have the same stack frame size as they are the same
> -# function called recursively.
> -stack_adjust = None
> +# List of FrameId instances, one for each stack frame.
> +frame_ids = []
> +
> +
> +def print_frame_ids():
> +    for i in range(len(frame_ids)):
> +        fid = frame_ids[i]
> +        print("frame-id for frame #%s: {stack=0x%x,code=0x%x}" % (i,
> fid.sp, fid.pc)) 
>  
>  class FrameId(object):
> @@ -49,16 +55,25 @@ class TestUnwinder(Unwinder):
>          if stop_at_level is None or pending_frame.level() !=
> stop_at_level: return None
>  
> -        if stack_adjust is None:
> -            raise gdb.GdbError("invalid stack_adjust")
> +        if len(frame_ids) < stop_at_level:
> +            raise gdb.GdbError("not enough parsed frame-ids")
>  
>          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
> -        unwinder = pending_frame.create_unwind_info(FrameId(sp, pc))
> +        # We're unwinding frame #n (n == pending_frame.level()), and are
> +        # expected to return:
> +        # - a frame ID for frame #n, and
> +        # - the register values for frame #(n+1), as saved in frame #n
> +        #
> +        # Instead, we return the frame ID for frame #n, and the register
> +        # values for frame #n.
> +        #
> +        # This will cause the backtrace stop at level #n, meaning:
> +        # - the entry for frame #n will be printed.
> +        # - the entry for frame #(n+1) will not be printed, instead
> +        #   "Backtrace stopped: <reason>" will be printed.
> +        unwinder =
> pending_frame.create_unwind_info(frame_ids[stop_at_level]) 
>          for reg in pending_frame.architecture().registers("general"):
>              val = pending_frame.read_register(reg)
> @@ -76,11 +91,18 @@ gdb.unwinder.register_unwinder(None, TestUnwinder(),
> True) #
>  #   main -> normal_func -> inline_func -> normal_func -> inline_func ->
> normal_func -> inline_func #
> -# Compute the stack frame size of normal_func, which has inline_func
> -# inlined within it.
> -f0 = gdb.newest_frame()
> -f1 = f0.older()
> -f2 = f1.older()
> -f0_sp = f0.read_register("sp")
> -f2_sp = f2.read_register("sp")
> -stack_adjust = f2_sp - f0_sp
> +# Iterate through frames 0 to 6, parse their frame-id and store it
> +# into the global FRAME_IDS list.
> +for i in range(7):
> +    # Get the frame-id in a verbose text form.
> +    output = gdb.execute("maint print frame-id %d" % i, to_string=True)
> +
> +    # Parse the frame-id in OUTPUT, find the stack and code addresses.
> +    match = re.search(r"stack=(0x[0-9a-fA-F]+).*?code=(0x[0-9a-fA-F]+)",
> output)
> +    if not match:
> +        raise gdb.GdbError("Could not parse frame-id for frame #%d" % i)
> +
> +    # Create the FrameId object.
> +    sp_addr = int(match.group(1), 16)
> +    pc_addr = int(match.group(2), 16)
> +    frame_ids.append(FrameId(sp_addr, pc_addr))
> 
> base-commit: 5606bf89ba974005089bb39bd23e944973fe60eb
> -- 
> 2.51.0
> 


  parent reply	other threads:[~2026-01-24 23:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-21 12:25 Tom de Vries
2026-01-21 17:10 ` Andrew Burgess
2026-01-21 17:21   ` Tom de Vries
2026-01-26 13:47     ` Andrew Burgess
2026-01-24 23:52 ` Kevin Buettner [this message]
2026-01-28 19:52 ` [PATCHv3] gdb: fix gdb.base/inline-frame-cycle-unwind.exp for s390x Andrew Burgess
2026-01-29  8:11   ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260124165233.7dabaf09@f42-mesa-1 \
    --to=kevinb@redhat.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox