[Bug gdb/12709] New: Stepping on a while loop freezes the GDB (MIPS platform)

[Bug gdb/12709] New: Stepping on a while loop freezes the GDB (MIPS platform)

[fyzmat at gmail dot com]

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

           Summary: Stepping on a while loop freezes the GDB (MIPS
                    platform)
           Product: gdb
           Version: 7.2
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: fyzmat@gmail.com


Hello,

I have encountered unexpected behaviour of the GDB. When I use the step command
on a while loop from one line of code, the GDB gets frozen. I believe, that the
GDB should stop the execution at the line with the loop.

Here is my scenario:
I debug remotely a program that is executed in MIPS R4000 machine simulator
(http://d3s.mff.cuni.cz/~holub/sw/msim/). I simplified problematic code to this
one:

int c = 0;
void bsp_start (void)
{
    while (c < 1000);
    print ("Initializing\n");    
}

I have done some research and obtained the debugging output from the simulator
that shows the remote communication with the GDB. This repeats forever:
<- s
-> T05thread:00000001;25:44250080;
<- s
-> T05thread:00000001;25:48250080;
<- s
-> T05thread:00000001;25:4c250080;
<- s
-> T05thread:00000001;25:50250080;
<- s
-> T05thread:00000001;25:54250080;

// s means the step command; 25:54250080 means the value of the pc 80002554

So I disassembled the simplified code:
 64       {
          bsp_start:
80002530:   addiu sp,sp,-24
80002534:   sw ra,20(sp)
80002538:   sw s8,16(sp)
8000253c:   move s8,sp
 65           while (c < 1000);
80002540:   nop 
80002544:   lui v0,0x8000
80002548:   lw v0,18032(v0)
8000254c:   slti v0,v0,1000
80002550:   bnez v0,0x80002544 <bsp_start+20>
80002554:   nop 
 67           print ("Initializing\n");
80002558:   lui v0,0x8000

This leads me to an idea that the GDB is just waiting, when the pc gets to the
80002558. After that I tried to debug the GDB and I finished in function
handle_inferior_event in file infrun.c on the code:

  /* If stepping through a line, keep going if still within it.

     Note that step_range_end is the address of the first instruction
     beyond the step range, and NOT the address of the last instruction
     within it!

     Note also that during reverse execution, we may be stepping
     through a function epilogue and therefore must detect when
     the current-frame changes in the middle of a line.  */

  if (stop_pc >= ecs->event_thread->step_range_start
      && stop_pc < ecs->event_thread->step_range_end
      && (execution_direction != EXEC_REVERSE
      || frame_id_eq (get_frame_id (frame),
              ecs->event_thread->step_frame_id)))
    {
      ...

      /* When stepping backward, stop at beginning of line range
     (unless it's the function entry point, in which case
     keep going back to the call point).  */
      if (stop_pc == ecs->event_thread->step_range_start
      && stop_pc != ecs->stop_func_start
      && execution_direction == EXEC_REVERSE)
    {
           ... // never happens in my case
    }
      else
    keep_going (ecs);

      return;
    }

The variable stop_pc has values from 0x80002544 to 0x80002554; the variable 
ecs->event_thread->step_range_start 0x80002540; and the variable
ecs->event_thread->step_range_end 0x80002558. This makes me more sure, that the
reason for the freezing is on the GDB side.

Regards,
Tomas

-- 
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.

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

[pedro at codesourcery dot com]

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

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pedro at codesourcery dot
                   |                            |com
         Resolution|                            |INVALID

--- Comment #1 from Pedro Alves <pedro at codesourcery dot com> 2011-04-27 19:50:57 UTC ---
int c = 0;
void bsp_start (void)
{
    while (c < 1000);

This is an infinite loop, since you never increment `c'.  The step command
tells gdb to step until a different source line is reached.  Since the program
never reaches a new line, GDB keeps single-stepping...  Sorry, doesn't look
like there's a GDB bug here.

-- 
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.

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

[fyzmat at gmail dot com]

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

fyzmat at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
           Severity|normal                      |enhancement

--- Comment #2 from fyzmat at gmail dot com 2011-04-27 20:38:28 UTC ---
Thanks for the answer,

I can understand, that the described behaviour is correct.

When I try to reproduce this in standart C desktop application, the GDB will
stop on the while line after the step command. So I considered the behaviour
bad.

The 'c' variable can be changed for example from another thread. From my point
of view this behaviour can be little uncomfortable for the programmer, because
when applying the step command the GDB will be frozen until the 'c' is changed.
This can take very long, because the GDB is just single stepping for all the
time. (In my case it takes minutes). Thus the programmer is forced to restart
the debugging session.

I will reopen the bug, because I am not sure, if anybody would notice the
resolved bug.

Tomas

-- 
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.

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

[pedro at codesourcery dot com]

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

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #3 from Pedro Alves <pedro at codesourcery dot com> 2011-04-27 21:27:24 UTC ---
> The 'c' variable can be changed for example from another thread. From my point
> of view this behaviour can be little uncomfortable for the programmer, because
> when applying the step command the GDB will be frozen until the 'c' is changed.
> This can take very long, because the GDB is just single stepping for all the
> time. (In my case it takes minutes). Thus the programmer is forced to restart
> the debugging session.

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.

> When I try to reproduce this in standart C desktop application, the GDB will
> stop on the while line after the step command. So I considered the behaviour
> bad.

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.

-- 
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.

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

[fyzmat at gmail dot com]

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.

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

[pedro at codesourcery dot com]

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

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.04.28 12:26:06
     Ever Confirmed|0                           |1

--- Comment #5 from Pedro Alves <pedro at codesourcery dot com> 2011-04-28 12:26:06 UTC ---
> 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.

>          bsp_start:
> 80002530:   addiu sp,sp,-24
> 80002534:   sw ra,20(sp)
> 80002538:   sw s8,16(sp)
> 8000253c:   move s8,sp
>  65           while (c < 1000);
> 80002540:   nop 

I see no branch/jump before the nop, so I take it the breakpoint would be hit
at least once, when stepping into the function.  I still don't understand what
you mean is different, as you haven't really pasted gdb session logs.

> 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).

I'm sure there's a "stop", "pause", "interrupt" or similarly named
button/action somewhere in your IDE.  It'd be a severely crippled IDE if it
didn't have such a basic feature.

-- 
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.

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

[fyzmat at gmail dot com]

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

--- Comment #6 from fyzmat at gmail dot com 2011-04-28 21:45:49 UTC ---
Created attachment 5695
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5695
Native gdb session

-- 
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.

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

[fyzmat at gmail dot com]

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

--- Comment #7 from fyzmat at gmail dot com 2011-04-28 21:46:28 UTC ---
Created attachment 5696
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5696
MIPS gdb session

-- 
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.

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

[fyzmat at gmail dot com]

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

--- Comment #8 from fyzmat at gmail dot com 2011-04-28 21:56:37 UTC ---
Hello,

> I'm sure there's a "stop", "pause", "interrupt" or similarly named
> button/action somewhere in your IDE.  It'd be a severely crippled IDE if it
> didn't have such a basic feature.

I attached two log files. In the native session the gdb hits the breakpoint on
the while line for each step command. In the MIPS session the gdb hits the
breakpoint only for the first time.

Personally I dont think that this difference is important. Just showing it,
when you get interested.

> I'm sure there's a "stop", "pause", "interrupt" or similarly named
> button/action somewhere in your IDE.  It'd be a severely crippled IDE if it
> didn't have such a basic feature.

Oh, of course it is. Sorry for being blind.

-- 
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.

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

[fyzmat at gmail dot com]

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

--- Comment #9 from fyzmat at gmail dot com 2011-04-28 21:58:04 UTC ---
Hello,

> I'm sure there's a "stop", "pause", "interrupt" or similarly named
> button/action somewhere in your IDE.  It'd be a severely crippled IDE if it
> didn't have such a basic feature.

I attached two log files. In the native session the gdb hits the breakpoint on
the while line for each step command. In the MIPS session the gdb hits the
breakpoint only for the first time.

Personally I dont think that this difference is important. Just showing it,
when you get interested.

> I'm sure there's a "stop", "pause", "interrupt" or similarly named
> button/action somewhere in your IDE.  It'd be a severely crippled IDE if it
> didn't have such a basic feature.

Oh, of course it is. Sorry for being blind.

-- 
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.

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

[pedro at codesourcery dot com]

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

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #10 from Pedro Alves <pedro at codesourcery dot com> 2011-04-29 10:02:53 UTC ---
> Personally I dont think that this difference is important.

Okay, nothing GDB can do here.

-- 
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.