[Bug tdep/32417] New: [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[Bug tdep/32417] New: [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

            Bug ID: 32417
           Summary: [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp:
                    backtrace
           Product: gdb
           Version: 14.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On s390x-linux, I ran into:
...
(gdb) PASS: gdb.base/readnever.exp: continue
backtrace^M
#0  0x000000000100061a in fun_three ()^M
#1  0x000000000100067a in fun_two ()^M
#2  0x000003fffdfa9470 in ?? ()^M
Backtrace stopped: frame did not save the PC^M
(gdb) FAIL: gdb.base/readnever.exp: backtrace
...

This seems to be related to the way this function handles saving fp (r11) and
sp (r15):
...
0000000001000608 <fun_three>:
 1000608:       b3 c1 00 2b             ldgr    %f2,%r11
 100060c:       b3 c1 00 0f             ldgr    %f0,%r15
 1000610:       e3 f0 ff 50 ff 71       lay     %r15,-176(%r15)
 1000616:       b9 04 00 bf             lgr     %r11,%r15
 100061a:       b9 04 00 12             lgr     %r1,%r2
 100061e:       b9 04 00 23             lgr     %r2,%r3
 1000622:       e3 40 b0 a0 00 24       stg     %r4,160(%r11)
 1000628:       50 10 b0 ac             st      %r1,172(%r11)
 100062c:       18 12                   lr      %r1,%r2
 100062e:       42 10 b0 ab             stc     %r1,171(%r11)
 1000632:       07 00                   nopr
 1000634:       b3 cd 00 b2             lgdr    %r11,%f2
 1000638:       b3 cd 00 f0             lgdr    %r15,%f0
 100063c:       07 fe                   br      %r14
 100063e:       07 07                   nopr    %r7
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/32417] [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|14.1                        |HEAD

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/32417] [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15821
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15821&action=edit
tentative patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/32417] [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2024-December/213821.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/32417] [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a64f365e6406bfe42feef3e64d88dfff11dddd5a

commit a64f365e6406bfe42feef3e64d88dfff11dddd5a
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Jan 9 14:32:19 2025 +0100

    [gdb/tdep] Fix gdb.base/readnever.exp on s390x

    On s390x-linux, I run into:
    ...
     (gdb) backtrace
     #0  0x000000000100061a in fun_three ()
     #1  0x000000000100067a in fun_two ()
     #2  0x000003fffdfa9470 in ?? ()
     Backtrace stopped: frame did not save the PC
     (gdb) FAIL: gdb.base/readnever.exp: backtrace
    ...

    This is really due to a problem handling the fun_three frame.  When
generating
    a backtrace from fun_two, everying looks ok:
    ...
     $ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \
         -ex "b fun_two" \
         -ex run \
         -ex bt
       ...
     #0  0x0000000001000650 in fun_two ()
     #1  0x00000000010006b6 in fun_one ()
     #2  0x00000000010006ee in main ()
    ...

    For reference the frame info with debug info (without -readnever) looks
like this:
    ...
    $ gdb -q -batch outputs/gdb.base/readnever/readnever \
        -ex "b fun_three" \
        -ex run \
        -ex "info frame"
      ...
    Stack level 0, frame at 0x3fffffff140:
     pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a
     called by frame at 0x3fffffff1f0
     source language c.
     Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c
     Locals at 0x3fffffff140, Previous frame's sp in v0
    ...

    But with -readnever, like this instead:
    ...
    Stack level 0, frame at 0x0:
     pc = 0x100061a in fun_three; saved pc = 0x100067a
     called by frame at 0x3fffffff140
     Arglist at 0xffffffffffffffff, args:
     Locals at 0xffffffffffffffff, Previous frame's sp in r15
    ...

    An obvious difference is the "Previous frame's sp in" v0 vs. r15.

    Looking at the code:
    ...
    0000000001000608 <fun_three>:
     1000608:       b3 c1 00 2b             ldgr    %f2,%r11
     100060c:       b3 c1 00 0f             ldgr    %f0,%r15
     1000610:       e3 f0 ff 50 ff 71       lay     %r15,-176(%r15)
     1000616:       b9 04 00 bf             lgr     %r11,%r15
    ...
    it becomes clear what is going on.  This is an unusual prologue.

    Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack,
    instead they're saved into call-clobbered floating point registers.

    [ For reference, this is the prologue of fun_two:
    ...
    0000000001000640 <fun_two>:
     1000640:       eb bf f0 58 00 24       stmg    %r11,%r15,88(%r15)
     1000646:       e3 f0 ff 50 ff 71       lay     %r15,-176(%r15)
     100064c:       b9 04 00 bf             lgr     %r11,%r15
    ...
    where the first instruction stores registers r11 to r15 to stack. ]

    Gdb fails to properly analyze the prologue, which causes the problems
getting
    the frame info.

    Fix this by:
    - adding handling of the ldgr insn [1] in s390_analyze_prologue, and
    - recognizing the insn as saving a register in
      s390_prologue_frame_unwind_cache.

    This gets us instead:
    ...
    Stack level 0, frame at 0x0:
     pc = 0x100061a in fun_three; saved pc = 0x100067a
     called by frame at 0x3fffffff1f0
     Arglist at 0xffffffffffffffff, args:
     Locals at 0xffffffffffffffff, Previous frame's sp in f0
    ...
    and:
    ...
     (gdb) backtrace^M
     #0  0x000000000100061a in fun_three ()^M
     #1  0x000000000100067a in fun_two ()^M
     #2  0x00000000010006b6 in fun_one ()^M
     #3  0x00000000010006ee in main ()^M
     (gdb) PASS: gdb.base/readnever.exp: backtrace
    ...

    Tested on s390x-linux.

    PR tdep/32417
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417

    Approved-By: Andreas Arnez <arnez@linux.ibm.com>

    [1]
https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/32417] [gdb/tdep, s390x] FAIL: gdb.base/readnever.exp: backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32417

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |17.1

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.