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

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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.