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

Ulrich Weigand
2011-10-10T14:39:22Z

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