[patch] Use displaced stepping regardless of SW single step

[patch] Use displaced stepping regardless of SW single step

[Yao Qi]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

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 (齐尧)

[-- Attachment #2: 0015-use-disp-step-regardless-of-sw-single-step.patch --]
[-- Type: text/x-patch, Size: 775 bytes --]

	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

Re: [patch] Use displaced stepping regardless of SW single step

[Yao Qi]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On 09/04/2011 09:54 PM, Yao Qi wrote:
> 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.
>

I made a mistake when comparing gdb.sum, and I run testsuite again this 
morning, and get something different on x86_64-pc-linux-gnu,

   - When displaced stepping is set to "auto", no regression.
   - When displaced stepping is set to "on", there are some new fails,
     * FAIL: gdb.base/ending-run.exp: step to end of run
       The test case doesn't match the output, while the output is correct.
     * FAIL: gdb.base/gdb1555.exp: Step into shared lib function
       FAIL: gdb.base/gdb1555.exp: Next while in a shared lib function
       FAIL: gdb.base/gnu-ifunc.exp: step
       FAIL: gdb.base/gnu-ifunc.exp: continue to break-at-nextcall
       FAIL: gdb.base/gnu-ifunc.exp: continue to breakpoint: nextcall 
gnu_ifunc
       FAIL: gdb.base/gnu-ifunc.exp: nextcall gnu_ifunc skipped
       These fails are caused by SIGSEGV in gdb, which shows some 
potential bugs in x86 displaced stepping.
     * FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw)
       FAIL: gdb.threads/pending-step.exp: next in multiple threads with 
breakpoints (timeout)
       They are similar to the problems (#4 and #5) I found on arm 
(posted http://sourceware.org/ml/gdb-patches/2011-08/msg00609.html), and 
I'll post other patches to fix them.

> -&&  (tp->control.trap_expected
> -	  || (step&&  gdbarch_software_single_step_p (gdbarch)))
> +&&  (tp->control.trap_expected || step))

There is an extra ")" added by mistake when I am adding changelog entry 
for this patch.  Here is the right one.

-- 
Yao (齐尧)

[-- Attachment #2: 0015-use-disp-step-regardless-of-sw-single-step.patch --]
[-- Type: text/x-patch, Size: 774 bytes --]

	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 7886cce..40e1d71 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1733,8 +1733,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

Re: [patch] Use displaced stepping regardless of SW single step

[Pedro Alves]

On Sunday 04 September 2011 14:54:21, Yao Qi wrote:
> 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,

But it is.  Displaced stepping is only necessary to step over breakpoints
(trap_expected) without removing them.  If there's no breakpoint at the
current instruction, we can just do a normal step.

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

From <http://sourceware.org/ml/gdb-patches/2009-06/msg00253.html>:

> > We still can't use software single-stepping simultaneously in multiple
> > threads.  Pedro, should we fix that or always use displaced stepping
> > for now?
> 
> It would be nice to have that fixed, for sure, so yes to the
> we should fix that question.  However, it seems to me that this
> is something that can be worked on mostly independently of the ARM
> bits as it's a general software single-step issue, not really ARM
> specific.  Unless someone wants to (and has time to) tackle it
> right now, I'd say go with the always displace-step version.  If
> nothing else, helps in stressing the displaced stepping
> implementation.  :-)

-- 
Pedro Alves

Re: [patch] Use displaced stepping regardless of SW single step

[Yao Qi]

On 09/06/2011 09:43 PM, Pedro Alves wrote:
> But it is.  Displaced stepping is only necessary to step over breakpoints
> (trap_expected) without removing them.  If there's no breakpoint at the
> current instruction, we can just do a normal step.

Yeah, that is true.  Looks my head has been oriented to software single 
step for a long time.  Please ignore my patch.

-- 
Yao (齐尧)