[Bug gdb/12709] Stepping on a while loop freezes the GDB (MIPSplatform)

["fyzmat at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12709

fyzmat at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #4 from fyzmat at gmail dot com 2011-04-28 09:03:27 UTC ---
(In reply to comment #3)

> Please paste a session showing what behavior is different between mips and the
> desktop version.  All I can think could be different is when stepping _into_
> the bsp_start function _the first time_, the mips version not stopping once
> before entering the loop.  That could be a debug info or prologue skipping
> issue, for example.  But I'll stop guessing until you paste a better log.

The difference can be reproduced under more specific circumstances, than I
thought at first. A breakpoint must be left on the loop to show it. The
application for the desktop hits the breakpoint and the MIPS application does
not hit it and steps forever.

This is a simple C program, which illustrates the difference:

/* test.c */
#include <stdio.h>

int c = 0;
int main(int argc, char **argv){
    while(c < 1000);
}

Compile it by command:
gcc -g -O0 -o test test.c

Run the gdb:
gdb test

Put the breakpoint to the main and debug the program:
break main
run

Apply the step command:
step

The GDB will stop on the while loop by hitting the breakpoint. In my MIPS
scenario, the GDB never hits the breakpoint.

The GDB for MIPS misses the breakpoint because the breakpoint is placed on the
80002540:   nop
instruction, which is not in the body of the loop.

Anyway, this difference does not bother me much. The stepping itself (without
the breakpoint) seems to work in a same way for both the platforms.

> The user does not need to restart the debug session. He can just interrupt the
> program, by pressing ctrl-c on the keyboard if debugging on the command line,
> or pressing whatever "interrupt" button the IDE gives her.  There is no problem
> here.  It's just how things work.

I can not remember that I see such an "interrupt" button in any IDE. At least
the Eclipse IDE (CDT plugin) does not seem to have it. Probably I will discuss
the addition of the button with the Eclipse community. (my job is make the
debugging work for the Eclipse IDE).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.