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