This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/12709] New: Stepping on a while loop freezes the GDB (MIPSplatform)
- From: "fyzmat at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 27 Apr 2011 19:17:41 +0000
- Subject: [Bug gdb/12709] New: Stepping on a while loop freezes the GDB (MIPSplatform)
- Auto-submitted: auto-generated
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.