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

[Tom de Vries <tdevries@suse.de>]

On 1/20/26 3:30 PM, Andrew Burgess wrote:
> Tom de Vries<tdevries@suse.de> 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.
> I don't believe this is how it works.  See below for what I think happens.
> 
>> [ 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 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.
> 
> It does appear that for frame #0 we get pending_frame.level() == 1, but
> this isn't what's really happening.
> 
> 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() == 1.
> 
> The frame-id calculated within TestUnwinder.__call__ is the frame-id for
> the previous (outer, older) frame.  So, when pending_frame.level() == 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 ( 
https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Unwinding-Frames-in-Python.html 
):
...
For the frames it can sniff an unwinder provides two additional methods: 
it can return frame’s ID, and it can fetch registers from the previous 
frame.

   ...

You implement a frame unwinder in Python as a class with which has two 
attributes, name and enabled, with obvious meanings, and a single method 
__call__, which examines a given frame and returns an object (an 
instance of gdb.UnwindInfo class) describing it. If an unwinder does not 
recognize a frame, it should return None. The code in GDB that enables 
writing unwinders in Python uses this object to return frame’s ID and 
previous frame registers when GDB core asks for them.
...
my understanding is that for pending_frame.level() == 5, we calculate 
the frame-id for frame #5.

On x86_64-linux, indeed that's the case, the output of maint print 
frame-id 5 matches the sp/pc calculated for pending_frame.level() == 5. 
This is shown in more detail in the commit message of the v2 I've submitted.

Thanks,
- Tom