Re: [try 2nd 5/8] Displaced stepping for Thumb 32-bit insns

["Ulrich Weigand" <uweigand@de.ibm.com>]

Yao Qi wrote:

> I don't have much details on hand for problem #6, but I can explain
> problem #7 a little bit here.  There are some kernel helpers on ARM in a
> high page (0xffffXXXX), and application can access them like this,
> 
> (gdb) disassemble 0x400eaba4,+4
> Dump of assembler code from 0x400eaba4 to 0x400eaba8:
> => 0x400eaba4:     sub     pc, r0, #31
> End of assembler dump.
> (gdb) p/x $r0
> $2 = 0xffff0fff
> 
> We have some bits in gdb to handle it
> (arm-linux-tdep.c:arm_catch_kernel_helper_return).  The problem here is
> that when inferior stops at such high address, gdb stops stepping and
> inserts a step-resume breakpoint, as shown in this log below,
> 
> displaced: stepping insn e240f01f at 40021ba4
> displaced: copying immediate ALU insn e240f01f
> displaced: read r0 value ffff0fff
> displaced: read r1 value 0d696914
> displaced: read r0 value ffff0fff
> displaced: read pc value 40021bac
> displaced: writing r0 value 40021bac
> displaced: writing r1 value ffff0fff
> displaced: writing insn e241001f at 000083ac
> displaced: copy 0x40021ba4->0x83ac: displaced: check mode of 40021ba4
> instead of 000083ac
> displaced: displaced pc to 0x83ac
> displaced: restored process 2067 0x83ac
> displaced: read r0 value ffff0fe0
> displaced: writing r0 value ffff0fff
> displaced: writing r1 value 0d696914
> displaced: writing pc ffff0fe0
> infrun: stop_pc = 0xffff0fe0
> infrun: stepped into undebuggable function
> 
> Obviously, it is not what we want here.  What we want here is to
> continue stepping, and then arm_catch_kernel_helper_return has the
> chance to handle PC at high address, and make everything correct.

I still don't quite understand what's wrong with the above sequence;
GDB displaced-stepped the "sub pc" command, recognized it was now in
an undebuggable function, and then inserted a step-resume breakpoint
to continue out of it.  This should work just fine, and should in
fact work the same in ARM mode too ...

The special code in arm_catch_kernel_helper_return is only needed if
we actually step in code *in* the kernel helper (i.e. if we do a
"si" on the "sub pc", and then *another* "si").  If *that* happens,
we should run into arm_catch_kernel_helper_return -- b.t.w. it seems
this function is then not Thumb-safe:
  dsc->modinsn[0] = 0xe59ef004;  /* ldr pc, [lr, #4].  */

I guess this needs to check for Thumb mode and produce an appropiate
instruction in that case ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com