This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch] Use displaced stepping regardless of SW single step
- From: Yao Qi <yao at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Sun, 04 Sep 2011 21:54:21 +0800
- Subject: [patch] Use displaced stepping regardless of SW single step
Hi,
I noticed that I can only do displaced stepping in first `si`, and in
the following `si', displaced stepping is not used at all, as shown below,
(gdb) set displaced-stepping on
(gdb) set debug displaced 1
(gdb) si
During symbol reading, incomplete CFI data; unspecified registers (e.g.,
rax) at 0x400565.
displaced: stepping process 32472 now
displaced: saved 0x400482: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0
displaced: copy 0x400564->0x400482: 55 48 89 e5 48 83 ec 10 e8 ff fe ff
ff 89 45 fc
displaced: displaced pc to 0x400482
displaced: run 0x400482: 55 48 89 e5
displaced: restored 0x400482
displaced: fixup (0x400564, 0x400482), insn = 0x55 0x48 ...
displaced: relocated %rip from 0x400483 to 0x400565
0x0000000000400565 24 {
(gdb) si
0x0000000000400568 24 {
(gdb) si
27 pid = fork ();
I don't think that is the expected behavior of gdb, so there may be
something wrong in gdb. The displaced stepping is controlled by this
condition check,
if (use_displaced_stepping (gdbarch)
&& (tp->control.trap_expected
|| (step && gdbarch_software_single_step_p (gdbarch)))
&& sig == TARGET_SIGNAL_0
&& !current_inferior ()->waiting_for_vfork_done)
This line of checking software_single_step_p was introduced in this
patch http://cygwin.com/ml/gdb-patches/2009-07/msg00395.html
(resume): If this is a software single-stepping arch, and
displaced-stepping is enabled, use it for all single-step
requests.
I don't figure out the reason we need to check software_single_step_p
here. We could do displaced stepping for targets support software
single step, and we could do displaced stepping for HW single step as well.
Regression tested on x86_64-unknown-linux-gnu with displaced stepping
"auto" and "on" respectively. No extra failures, but there are two
PASSes changed to KFAILs,
-PASS: gdb.cp/annota2.exp: watch triggered on a.x
+KFAIL: gdb.cp/annota2.exp: watch triggered on a.x (PRMS: gdb/38)
-PASS: gdb.cp/annota3.exp: watch triggered on a.x
+KFAIL: gdb.cp/annota3.exp: watch triggered on a.x (PRMS: gdb/38)
I am not familiar with this case, so can't tell this is caused by my patch.
--
Yao (éå)
gdb/
* infrun.c (resume): Use displaced stepping regardless of supporting
software single step.
---
gdb/infrun.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index bfef09c..bc4ca27 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1725,8 +1725,7 @@ a command like `return' or `jump' to continue execution."));
event, displaced stepping breaks the vfork child similarly as single
step software breakpoint. */
if (use_displaced_stepping (gdbarch)
- && (tp->control.trap_expected
- || (step && gdbarch_software_single_step_p (gdbarch)))
+ && (tp->control.trap_expected || step))
&& sig == TARGET_SIGNAL_0
&& !current_inferior ()->waiting_for_vfork_done)
{
--
1.7.0.4