[Bug tdep/30021] [gdb/tdep, powerpc64le] previous frame inner to this frame (corrupt stack?)

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #7 from cvs-commit at gcc dot gnu.org <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=5f6ec13ffe8ae4db04419bf66868e082df73634d

commit 5f6ec13ffe8ae4db04419bf66868e082df73634d
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Jan 25 13:27:03 2023 +0100

    [gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp

    In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function
foo
    to check various invariants at each insn, in particular hoping to excercise
    insns that modify stack and frame pointers.

    For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
    ...
      4004bc:       55                      push   %rbp
      4004bd:       48 89 e5                mov    %rsp,%rbp
      4004c0:       90                      nop
      4004c1:       5d                      pop    %rbp
      4004c2:       c3                      ret
    ...
    Both stack pointer (%rsp) and frame pointer (%rbp) are modified.

    Also for s390x-linux (and similar for -m31):
    ...
    0000000001000668 <foo>:
     1000668:       e3 b0 f0 58 00 24       stg     %r11,88(%r15)
     100066e:       b9 04 00 bf             lgr     %r11,%r15
     1000672:       e3 b0 b0 58 00 04       lg      %r11,88(%r11)
     1000678:       07 fe                   br      %r14
    ...
    Frame pointer (%r11) is modified.

    Likewise for powerpc64le-linux:
    ...
    00000000100006c8 <foo>:
        100006c8:   f8 ff e1 fb     std     r31,-8(r1)
        100006cc:   d1 ff 21 f8     stdu    r1,-48(r1)
        100006d0:   78 0b 3f 7c     mr      r31,r1
        100006d4:   00 00 00 60     nop
        100006d8:   30 00 3f 38     addi    r1,r31,48
        100006dc:   f8 ff e1 eb     ld      r31,-8(r1)
        100006e0:   20 00 80 4e     blr
    ...
    Both stack pointer (r1) and frame pointer (r31) are modified.

    But for aarch64-linux, we have:
    ...
    00000000004005fc <foo>:
      4005fc:       d503201f        nop
      400600:       d65f03c0        ret
    ...
    There's no insn that modifies stack or frame pointer.

    Fix this by making foo more complex, adding an (unused) argument:
    ...
    0000000000400604 <foo>:
      400604:       d10043ff        sub     sp, sp, #0x10
      400608:       f90007e0        str     x0, [sp, #8]
      40060c:       d503201f        nop
      400610:       910043ff        add     sp, sp, #0x10
      400614:       d65f03c0        ret
    ...
    such that the stack pointer (sp) is modified.

    [ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
    -mno-omit-leaf-frame-pointer we have instead:
    ...
    0000000000400604 <foo>:
      400604:       a9be7bfd        stp     x29, x30, [sp, #-32]!
      400608:       910003fd        mov     x29, sp
      40060c:       f9000fa0        str     x0, [x29, #24]
      400610:       d503201f        nop
      400614:       a8c27bfd        ldp     x29, x30, [sp], #32
      400618:       d65f03c0        ret
    ...
    such that also the frame pointer (x29) is modified. ]

    Having made foo more complex, we now run into the following fail on
    x86_64/-m32:
    ...
    FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value ==
$main_sp
    ....

    The problem is that the stack pointer has changed inbetween the sampling of
    main_sp and *foo, in particular by the push insn:
    ...
     804841a:       68 c0 84 04 08          push   $0x80484c0
     804841f:       e8 10 00 00 00          call   8048434 <foo>
    ...

    Fix this by updating main_sp.

    On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
    ...
    FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
    FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid
$main_fid]
    ...
    but I saw the same failure before this commit with gcc 4.8.5.

    Tested on:
    - x86_64-linux (-m64 and -m32)
    - s390x-linux (-m64 and -m31)
    - powerpc64le-linux
    - aarch64-linux

    Also I've checked that the test-case still functions as regression test for
PR
    record/16678 on x86_64.

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