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

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

[vries at gcc dot gnu.org]

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

            Bug ID: 30021
           Summary: [gdb/tdep, powerpc64le] previous frame inner to this
                    frame (corrupt stack?)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the following two-source test-case:
...
$ cat test.c
extern void foo (const char *);

int
main (void)
{
  foo ("foo");
  return 0;
}
$ cat test2.c
void
foo (const char *s)
{
}
...

Compiled like so:
...
$ gcc test2.c -c; gcc test.c -g test2.o
...
So, test2.c without debug info, test.c with debug info.

Disassembly of foo:
...
00000000100006b0 <foo>:
    100006b0:   f8 ff e1 fb     std     r31,-8(r1)
    100006b4:   c1 ff 21 f8     stdu    r1,-64(r1)
    100006b8:   78 0b 3f 7c     mr      r31,r1
    100006bc:   20 00 7f f8     std     r3,32(r31)
    100006c0:   00 00 00 60     nop
    100006c4:   40 00 3f 38     addi    r1,r31,64
    100006c8:   f8 ff e1 eb     ld      r31,-8(r1)
    100006cc:   20 00 80 4e     blr
        ...
    100006d8:   80 01 00 01     .long 0x1000180
    100006dc:   00 00 00 60     nop
...

Disassembly of main:
...
000000001000065c <main>:
    1000065c:   02 10 40 3c     lis     r2,4098
    10000660:   00 7f 42 38     addi    r2,r2,32512
    10000664:   a6 02 08 7c     mflr    r0
    10000668:   10 00 01 f8     std     r0,16(r1)
    1000066c:   f8 ff e1 fb     std     r31,-8(r1)
    10000670:   d1 ff 21 f8     stdu    r1,-48(r1)
    10000674:   78 0b 3f 7c     mr      r31,r1
    10000678:   fe ff 62 3c     addis   r3,r2,-2
    1000067c:   40 89 63 38     addi    r3,r3,-30400
    10000680:   31 00 00 48     bl      100006b0 <foo>
    10000684:   00 00 00 60     nop
    10000688:   00 00 20 39     li      r9,0
    1000068c:   78 4b 23 7d     mr      r3,r9
    10000690:   30 00 3f 38     addi    r1,r31,48
    10000694:   10 00 01 e8     ld      r0,16(r1)
    10000698:   a6 03 08 7c     mtlr    r0
    1000069c:   f8 ff e1 eb     ld      r31,-8(r1)
    100006a0:   20 00 80 4e     blr
    100006a4:   00 00 00 00     .long 0x0
    100006a8:   00 00 00 01     .long 0x1000000
    100006ac:   80 01 00 01     .long 0x1000180
...

With this gdb session, we get a 'corrupt stack?' message:
...
$ gdb -q -batch a.out \
    -ex start \
    -ex "display /i \$pc" \
    -ex "si 9" \
    -ex up \
    -ex "info frame"
Temporary breakpoint 1 at 0x10000678: file test.c, line 6.

Temporary breakpoint 1, main () at test.c:6
6         foo ("foo");
0x00000000100006c8 in foo ()
1: x/i $pc
=> 0x100006c8 <foo+24>: ld      r31,-8(r1)
#1  0x0000000010000684 in main () at test.c:6
6         foo ("foo");
Stack level 1, frame at 0x7fffffffeec0:
 pc = 0x10000684 in main (test.c:6); saved pc = <not saved>
 Outermost frame: previous frame inner to this frame (corrupt stack?)
 caller of frame at 0x7fffffffeed0
 source language c.
 Arglist at 0x7fffffffee90, args: 
 Locals at 0x7fffffffee90, Previous frame's sp is 0x7fffffffeec0
 Saved registers:
  r31 at 0x7fffffffeeb8, pc at 0x7fffffffeed0, lr at 0x7fffffffeed0
...

We don't get that message with "si 8" or "si 10".

Also, if I drop the -g, we don't get that message.

Likewise, if I add -g for both source files, we don't get that message.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
PR mentioned here:
https://sourceware.org/pipermail/gdb-patches/2023-January/195920.html

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

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

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cel at us dot ibm.com,
                   |                            |kevinb at redhat dot com,
                   |                            |ulrich.weigand at de dot ibm.com

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
With gcc 4.8.5, I'm running into FAILs in gdb.base/unwind-on-each-insn.exp,
which I assume are a duplicate of this one, for the reason that the same insn
triggers the problem:
...
FAIL: gdb.base/unwind-on-each-insn.exp: instruction 5: $fba_value == $main_fba
FAIL: gdb.base/unwind-on-each-insn.exp: instruction 5: [string equal $fid
$main_fid]
...

Disassembly of foo:
...
00000000100006dc <foo>:
    100006dc:   f8 ff e1 fb     std     r31,-8(r1)
    100006e0:   d1 ff 21 f8     stdu    r1,-48(r1)
    100006e4:   78 0b 3f 7c     mr      r31,r1
    100006e8:   30 00 3f 38     addi    r1,r31,48
    100006ec:   f8 ff e1 eb     ld      r31,-8(r1)
    100006f0:   20 00 80 4e     blr
...

Minimal reproducer:
...
$ gdb -q -batch outputs/gdb.base/unwind-on-each-insn/unwind-on-each-insn \
  -ex "set trace-commands on" \
  -ex "b *foo + 12" \
  -ex "display /x \$r1" \
  -ex "display /x \$r31" \
  -ex run \
  -ex "info frame" \
  -ex "si" \
  -ex "info frame" \
  -ex si \
  -ex "info frame"
+b *foo + 12
Breakpoint 1 at 0x100006e8
+display /x $r1
+display /x $r31
+run

Breakpoint 1, 0x00000000100006e8 in foo ()
1: /x $r1 = 0x7fffffffec80
2: /x $r31 = 0x7fffffffec80
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006e8 in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffed20
 Arglist at 0x7fffffffec80, args: 
 Locals at 0x7fffffffec80, Previous frame's sp is 0x7fffffffecb0
 Saved registers:
  r31 at 0x7fffffffeca8
+si
0x00000000100006ec in foo ()
1: /x $r1 = 0x7fffffffecb0
2: /x $r31 = 0x7fffffffec80
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006ec in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffecf0
 Arglist at 0x7fffffffec80, args: 
 Locals at 0x7fffffffec80, Previous frame's sp in r1
+si
0x00000000100006f0 in foo ()
1: /x $r1 = 0x7fffffffecb0
2: /x $r31 = 0x7fffffffecb0
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006f0 in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffed20
 Arglist at 0x7fffffffecb0, args: 
 Locals at 0x7fffffffecb0, Previous frame's sp in r1
...

Note this line:
...
 called by frame at 0x7fffffffed20
  ...
 called by frame at 0x7fffffffecf0
  ...
 called by frame at 0x7fffffffed20
...

It's correct for the insn first insn (at 100006e8), which is not unwound by the
epilogue unwinder.

It's also correct for the last insn (at 100006f0), which is unwound by the
epilogue unwinder.

It not correct for the middle insn (at 100006ec), which is also unwound by the
epilogue unwinder.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
I analyzed this down to rs6000_epilogue_frame_prev_register giving the wrong
value for r31 at that insn.

This fix (or workaround?) make the test-case pass:
...
diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
index 592b447..45b4454 100644
--- a/gdb/rs6000-tdep.c
+++ b/gdb/rs6000-tdep.c
@@ -3852,6 +3852,20 @@ struct rs6000_frame_cache
 {
   struct rs6000_frame_cache *info =
     rs6000_epilogue_frame_cache (this_frame, this_cache);
+  if (regnum == 31)
+    /* In foo, we get rs6000_in_function_epilogue_frame_p == 1 starting
+       the insn at 0x100006ec.
+         00000000100006dc <foo>:
+        100006dc:   f8 ff e1 fb     std     r31,-8(r1)
+        100006e0:   d1 ff 21 f8     stdu    r1,-48(r1)
+        100006e4:   78 0b 3f 7c     mr      r31,r1
+        100006e8:   30 00 3f 38     addi    r1,r31,48
+        100006ec:   f8 ff e1 eb     ld      r31,-8(r1)
+        100006f0:   20 00 80 4e     blr
+       However, r31 is only restored after executing that insn, so asking for
+       r31 at 0x100006ec will just read the reg and return the wrong value.
+       Workaround this by getting r1 instead.  */
+    regnum = 1;
   return trad_frame_get_prev_register (this_frame, info->saved_regs, regnum);
 }

...

Using the patch, we have instead:
...
+b *foo + 12
Breakpoint 1 at 0x100006e8
+display /x $r1
+display /x $r31
+run

Breakpoint 1, 0x00000000100006e8 in foo ()
1: /x $r1 = 0x7fffffffec80
2: /x $r31 = 0x7fffffffec80
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006e8 in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffed20
 Arglist at 0x7fffffffec80, args: 
 Locals at 0x7fffffffec80, Previous frame's sp is 0x7fffffffecb0
 Saved registers:
  r31 at 0x7fffffffeca8
+si
0x00000000100006ec in foo ()
1: /x $r1 = 0x7fffffffecb0
2: /x $r31 = 0x7fffffffec80
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006ec in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffed20
 Arglist at 0x7fffffffec80, args: 
 Locals at 0x7fffffffec80, Previous frame's sp in r1
+si
0x00000000100006f0 in foo ()
1: /x $r1 = 0x7fffffffecb0
2: /x $r31 = 0x7fffffffecb0
+info frame
Stack level 0, frame at 0x7fffffffecb0:
 pc = 0x100006f0 in foo; saved pc = 0x100006b0
 called by frame at 0x7fffffffed20
 Arglist at 0x7fffffffecb0, args: 
 Locals at 0x7fffffffecb0, Previous frame's sp in r1
...

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

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

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> I analyzed this down to rs6000_epilogue_frame_prev_register giving the wrong
> value for r31 at that insn.
> 
> This fix (or workaround?) make the test-case pass:
> ...
> diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
> index 592b447..45b4454 100644
> --- a/gdb/rs6000-tdep.c
> +++ b/gdb/rs6000-tdep.c
> @@ -3852,6 +3852,20 @@ struct rs6000_frame_cache
>  {
>    struct rs6000_frame_cache *info =
>      rs6000_epilogue_frame_cache (this_frame, this_cache);
> +  if (regnum == 31)
> +    /* In foo, we get rs6000_in_function_epilogue_frame_p == 1 starting
> +       the insn at 0x100006ec.
> +         00000000100006dc <foo>:
> +        100006dc:   f8 ff e1 fb     std     r31,-8(r1)
> +        100006e0:   d1 ff 21 f8     stdu    r1,-48(r1)
> +        100006e4:   78 0b 3f 7c     mr      r31,r1
> +        100006e8:   30 00 3f 38     addi    r1,r31,48
> +        100006ec:   f8 ff e1 eb     ld      r31,-8(r1)
> +        100006f0:   20 00 80 4e     blr
> +       However, r31 is only restored after executing that insn, so asking
> for
> +       r31 at 0x100006ec will just read the reg and return the wrong value.
> +       Workaround this by getting r1 instead.  */
> +    regnum = 1;
>    return trad_frame_get_prev_register (this_frame, info->saved_regs,
> regnum);
>  }
>  
> ...
> 

Testing when fine, but I think this approach is too rough.

I found that r31 is mostly used for frame pointer, but on darwin r30 is used
instead, so we just can't make the assumption that r1 will have the value of
r31.

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

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

[vries at gcc dot gnu.org]

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

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

A hopefully more robust approach: detect stack restores in the epilogue and
save the corresponding values in the epilogue cache.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> Created attachment 14611 [details]
> Tentative untested patch
> 
> A hopefully more robust approach: detect stack restores in the epilogue and
> save the corresponding values in the epilogue cache.

Only changes in full test run:
...
-FAIL: gdb.base/unwind-on-each-insn.exp: instruction 5: $fba_value == $main_fba
-FAIL: gdb.base/unwind-on-each-insn.exp: instruction 5: [string equal $fid
$main_fid]
+PASS: gdb.base/unwind-on-each-insn.exp: instruction 5: $fba_value == $main_fba
+PASS: gdb.base/unwind-on-each-insn.exp: instruction 5: [string equal $fid
$main_fid]
...

Well, that's not bad.

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

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

[cvs-commit at gcc dot gnu.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.

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

[cel at us dot ibm.com]

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

--- Comment #8 from Carl E Love <cel at us dot ibm.com> ---
I am seeing 11 new failures on our GDB build bot runs.  They appear to be due
to the latest commit.  There appear to be a couple of issues fixed.  

158 failures
11 new failures
3 old failures fixed

+FAIL: gdb.base/gdb-sigterm.exp: pass=1: expect eof (GDB internal error)
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: bt 2
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: [string equal $fid
$::main_fid]
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: up
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: bt 2
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: [string equal $fid
$::main_fid]
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: up
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 8: $fba_value ==
$::main_fba
+FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 8: [string equal $fid
$::main_fid]
+FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 7: $fba_value ==
$::main_fba
+FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 7: [string equal $fid
$::main_fid]
-FAIL: gdb.base/gdb-sigterm.exp: pass=0: expect eof (GDB internal error)
-FAIL: gdb.base/unwind-on-each-insn.exp: instruction 6: $fba_value == $main_fba
-FAIL: gdb.base/unwind-on-each-insn.exp: instruction 6: [string equal $fid
$main_fid]

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

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

[cel at us dot ibm.com]

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

--- Comment #9 from Carl E Love <cel at us dot ibm.com> ---
I should have noted that the new failures occur on both Power 9 and Power 10.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #8)
> I am seeing 11 new failures on our GDB build bot runs.  They appear to be
> due to the latest commit.  There appear to be a couple of issues fixed.  
> 
> 158 failures
> 11 new failures
> 3 old failures fixed
> 
> +FAIL: gdb.base/gdb-sigterm.exp: pass=1: expect eof (GDB internal error)
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: bt 2
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: [string equal
> $fid $::main_fid]
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 6: up
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: bt 2
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: [string equal
> $fid $::main_fid]
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 7: up
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 8: $fba_value ==
> $::main_fba
> +FAIL: gdb.base/unwind-on-each-insn.exp: bar: instruction 8: [string equal
> $fid $::main_fid]
> +FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 7: $fba_value ==
> $::main_fba
> +FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 7: [string equal
> $fid $::main_fid]
> -FAIL: gdb.base/gdb-sigterm.exp: pass=0: expect eof (GDB internal error)
> -FAIL: gdb.base/unwind-on-each-insn.exp: instruction 6: $fba_value ==
> $main_fba
> -FAIL: gdb.base/unwind-on-each-insn.exp: instruction 6: [string equal $fid
> $main_fid]

See also PR30049.

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