This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]