Re: [PATCH] [gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x (alternative)

[Kevin Buettner <kevinb@redhat.com>]

Hi Tom,

On Thu, 11 Dec 2025 14:39:46 +0100
Tom de Vries <tdevries@suse.de> wrote:

> 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. ]
> 
> 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.

Thanks for looking into this.  I like this approach better the one
that I took - fixing the frame-id source so the test works uniformly
across architectures is cleaner than adjusting expectations
per architecture.

One issue: I think that your patch leaves some dead code in the
Python file.  With stack_adjust no longer used, it seems to me that
the following should be removed:

1. The variable declaration / initialization:

   stack_adjust = None

2. The check:

    if stack_adjust is None:
      raise gdb.GdbError("invalid stack_adjust")

3. The computation at module load time:

    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

Kevin