From: Changbin Du <[email protected]>
Recently when debugging an arm32 system on qemu, I found sometimes the
single-step command (stepi) is not working. This can be reproduced by
below steps:
1) start qemu-system-arm -s -S .. and wait for gdb connection.
2) start gdb and connect to qemu. In my case, gdb gets a wrong value
(0x60) for PC, which is an another bug.
3) After connected, type 'stepi' and expect it will stop at next ins.
But, it has never stopped. This because:
1) We doesn't report ‘vContSupported’ feature to gdb explicitly and gdb
think we do not support it. In this case, gdb use a software breakpoint
to emulate single-step.
2) Since gdb gets a wrong initial value of PC, then gdb inserts a
breakpoint to wrong place (PC+4).
Not only for the arm target, Philippe has also encountered this on MIPS.
Probably gdb has different assumption for different architectures.
Since we do support ‘vContSupported’ query command, so let's tell gdb that
we support it.
Before this change, gdb send below 'Z0' packet to implement single-step:
gdb_handle_packet: Z0,4,4
After this change, gdb send "vCont;s.." which is expected:
gdb_handle_packet: vCont?
put_packet: vCont;c;C;s;S
gdb_handle_packet: vCont;s:p1.1;c:p1.-1
Signed-off-by: Changbin Du <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
[AJB: fix for static gdbstub]
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Luc Michel <[email protected]>
---
gdbstub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdbstub.c b/gdbstub.c
index 9ae148cd1ff..013fb1ac0f1 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -2130,7 +2130,7 @@ static void handle_query_supported(GdbCmdContext
*gdb_ctx, void *user_ctx)
gdbserver_state.multiprocess = true;
}
- g_string_append(gdbserver_state.str_buf, ";multiprocess+");
+ g_string_append(gdbserver_state.str_buf, ";vContSupported+;multiprocess+");
put_strbuf();
}
--
2.20.1
