Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Jason Molenda <jason-swarelist@molenda.com>]

On Mon, Feb 03, 2003 at 01:34:41PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 03, 2003 at 10:27:48AM -0800, Jason Molenda wrote:
> > On Mon, Feb 03, 2003 at 10:15:20AM -0800, David Carlton wrote:
> > 
> > > 
> > > On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:
> > > 
> > 
> > > PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
> > > FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue

> The exec-continue failure seems to be a bad regular expression - it's
> expecting "*stopped[\r\n]+", not any of the things which follow
> *stopped.  

The problem is that a breakpoint on this function:

void
subroutine (int in)
{
  while (in < 100)
    in++;
}

will be triggered each time in the loop.  e.g.

[jason@little-green-moose gdb.mi]$ ../../gdb -q ./mi-syn-frame
(gdb) b main
Breakpoint 1 at 0x8048408: file ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c, line 14.
(gdb) run
Starting program: /home/jason/sware/gdb/b/gdb/testsuite/gdb.mi/mi-syn-frame

Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:14
14        puts ("Starting up");
(gdb) b subroutine
Breakpoint 2 at 0x8048530: file ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c, line 49.
(gdb) call subroutine(5)

Breakpoint 2, subroutine (in=5)
    at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:49
49        while (in < 100)
The program being debugged stopped while in a function called from GDB.
When the function (subroutine) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) cont
Continuing.

Breakpoint 2, subroutine (in=6)
    at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:49
49        while (in < 100)
(gdb) cont
Continuing.
[etc]

It's failing for both stabs and for DWARF with gcc 3.2 (the one
included in RH 8).  In both cases, gdb is putting the breakpoint
on the cmpl at subroutine+4 so it's hit each time we iterate the loop:

(gdb) x/10i subroutine
0x804852c <subroutine>: push   %ebp
0x804852d <subroutine+1>:       mov    %esp,%ebp
0x804852f <subroutine+3>:       nop
0x8048530 <subroutine+4>:       cmpl   $0x63,0x8(%ebp)
0x8048534 <subroutine+8>:       jle    0x8048538 <subroutine+12>
0x8048536 <subroutine+10>:      jmp    0x8048540 <subroutine+20>
0x8048538 <subroutine+12>:      incl   0x8(%ebp)
0x804853b <subroutine+15>:      jmp    0x8048530 <subroutine+4>
0x804853d <subroutine+17>:      lea    0x0(%esi),%esi
0x8048540 <subroutine+20>:      pop    %ebp

But when I compile the same test program with gcc 2.96, gdb is
putting the breakpoint on subroutine+3 - the nop - and things
work as expected.


My promise to fix this this evening assumed it was a dumb little
testsuite regexp problem - this is novel enough (read: Not My Fault :) 
that I'm instead going to bed as it's about bedtime...  I'll look
back into this tomorrow night when I get home if no one else
recognizes why this problem might be coming up.

Jason