This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [try 2nd 5/8] Displaced stepping for Thumb 32-bit insns
- From: Yao Qi <yao at codesourcery dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 10 Oct 2011 09:41:03 +0800
- Subject: Re: [try 2nd 5/8] Displaced stepping for Thumb 32-bit insns
- References: <201109141339.p8EDddLk024568@d06av02.portsmouth.uk.ibm.com>
On 09/14/2011 09:39 PM, Ulrich Weigand wrote:
>> > 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.
> I'm afraid I don't quite understand those last two points. Could you
> elaborate what exactly is going wrong?
>
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.
--
Yao (éå)