Move threads out of jumppad without single step

[Yao Qi <qiyaoltc at gmail dot com>]

Hi Pedro,
Can we move threads out of jumppad without using single step?  I mean,
supposing GDBserver can compute the next PCs of the instruction on which
fast tracepoint is set, GDBserver can insert breakpoints at the next PCs
of the instruction fast tracepoint is set on, and resume the thread
which is in jumppad.

In the recent discussion about ARM fast tracepoint support, I pointed
out that missing hardware single step may be a showstopper to ARM fast
tracepoint support, but Simon wants to convince me that we can have a
non-perfect fast tracepoint support on ARM with software single step.
After I think about the possible issues of using software single step, I
don't have any outcomes, but I wonder why do we need to single step
thread out of jumppad?  Here is my understanding, in the jumppad, the
instructions are like,

  saved registers
  spin lock
  call gdb_collect
  spin unlock
  restore registers
  <----- [1]
  relocated instructions
  jump back

If PC is within the range above, GDBserver needs to move the thread
out.  GDBserver can single step instructions one by one until PC is out
of this range, but we have an optimization here that GDBserver can
insert breakpoint and resume rather than single step one by one if PC
doesn't point to the relocated instructions yet [1].  Afterwards,
GDBserver will single step, but there aren't many instructions.  Unless
I miss something, the code comments explain why do we move threads out
of jumppad, but they do *not* explain why do we move threads out of
jumppad in this way.  IMO, the reason is that instructions before [1]
are sequentially executed (except call gdb_collect), but instructions
after [1] may not.  We can safely insert breakpoint on [1], and thread
must hit the breakpoint.  However, the original instruction on which the
fast tracepoint is set may be a branch instruction, so the relocated
instructions may jump back to the target address.  At the moment we add
fast tracepoint support (for x86), we rely on hardware single step so
that we don't have to compute the next PCs (that is also the reason why
qRelocInsn packet was added).

Now, the situation in GDBserver changed a little bit, as GDBserver will
be able to accurately compute the next PCs.  Under this assumption,
GDBserver can compute the next PCs of the original instruction, and set
breakpoints there when threads are in jumppad.  In this way, we don't
need to single step thread out jumppad at all for targets which support
software single step in GDBserver.

-- 
Yao (éå)