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

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

On Tue, Feb 04, 2003 at 12:09:36AM -0800, Jason Molenda wrote:
> 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.  


It's not really a compiler bug and not really a debugger bug.  
For this function -

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

gcc 3.2 is outputting debug info like this -

        .stabs  "subroutine:F(9,7)",36,0,0,subroutine
        .stabs  "in:p(0,1)",160,0,0,8
.globl subroutine
        .type   subroutine,@function
subroutine:
        .stabn 68,0,48,.LM18-subroutine
.LM18:
        pushl   %ebp
        movl    %esp, %ebp
        nop
        .stabn 68,0,49,.LM19-subroutine    ; line #49 is the while (...)
.LM19:
.L6:
        cmpl    $99, 8(%ebp)
        jle     .L8
        jmp     .L5
.L8:

The compiler is correct to put the line stab there (it does the
equivalent for DWARF2), and gdb is correct in putting the breakpoint
on the cmpl insn, but the unfortunate end result of these two is that
a user putting a breakpoint on the subroutine will have a breakpoint
that's tripped each iteration of the loop.

Given all that, I'll check in a change to mi-syn-frames.c so this
function reads

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

The assignment gives us two assembly instructions after the end of the
prologue for a breakpoint that won't be hit at each iteration.  It's
stupid, I know.

I'll make that change and run it through the testsuites tomorrow
night.  If I get approval for the change before then (hint hint :)
I'll check it in, else I'll post a patch.

J