[Bug gdb/12709] New: 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

           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.