On 08/20/2011 12:39 AM, Ulrich Weigand wrote:
> Since this is (together with the previous patches that are not yet committed)
> is a significant change, I'm wondering a bit what additional testing we could
> do to catch any possibly remaining issues ...
>
> Did you try a testsuite run with a GDB build that forces displaced-stepping
> on by default?  (I.e. change the initializer of can_use_displaced_stepping
> in infrun.c to can_use_displaced_stepping_on.)  That would exercise the new
> code a lot.

Yes, I run gdb testsuite with can_use_displaced_stepping set to 
can_use_displaced_stepping_on, and it does expose more problems in 
current patches.  Three patches attached here to address these problems 
found so far.  I don't combine them into one patch, because they belongs 
to different groups (thumb 16bit, thumb 32bit).

After applied these three patches, there are still some failures, which 
are caused by some reasons, so these three patches here can be regarded 
as WIP patches.

   1.  Failures in gdb.arch/thumb2-it.exp and gdb.base/gdb1555.exp. 
These failures are caused by missing IT support in thumb displaced stepping.

   2.  Failures in gdb.base/break-interp.exp and gdb.base/nostdlib.exp. 
  They are appeared on i686-pc-linux-gnu as well.

   3.  Failures (timeout) in gdb.base/sigstep.exp.  IIUC, it is 
incorrect to displaced step instructions in signal handler, so failures 
are expected.

   4.  Failures in gdb.base/watch-vfork.exp.  Displaced stepping is not 
completed due to a VFORK event.  Current displaced stepping 
infrastructure or infrun logic doesn't consider the case that executing 
instruction in scratch can be "interrupted".  When displaced stepping an 
vfork syscall, VFORK event comes out earlier than TRAP event.  GDB will 
be confused.

   5. Timeout failures in gdb.threads/*.exp.  Similarly to #4, when 
execution instructions in scratch, thread context switch may happen, and 
GDB will be confused as well.  #4 and #5 are not arm-specific problem.

   6. Failures in gdb.base/watchpoint-solib.exp gdb.mi/mi-simplerun.exp. 
  They are caused by displaced stepping instruction `mov r12, #imm`. 
This instruction should be unmodified-copied to scratch, and execute, 
but experiment shows we can't.  I have a local patch that can control 
displaced stepping on instructions' level.  Once I turn it on for `mov 
r12, #imm`, these tests will fail.  The reason is still unknown to me.

   7. Accessing some high addresses.  Some instructions (alu_imm) may 
set PC to a hight address, such as 0xffffxxxx, and displaced stepping of 
this kind instruction should be handled differently.

If my analysis above makes sense and is correct, we still have to fix #1 
at least, to make displaced stepping really works.  On the other hand, 
if current patches can be approved, I am happy as well, and can carry 
less local patches to move on. :)

-- 
Yao (齐尧)