Re: [PATCH] ARM: vfp: Fix up exception location in Thumb mode

[Catalin Marinas]

On 14 January 2011 18:47, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 14, 2011 at 05:30:50PM +0000, Russell King - ARM Linux wrote:
>> On Fri, Jan 14, 2011 at 04:58:47PM +0000, Catalin Marinas wrote:
>> > I agree, this code needs some clean-up. Maybe for Undef we could unify
>> > the ARM and Thumb-2 offsets so that they are both 4 (it may confuse the
>> > breakpoint code, I haven't checked).
>> >
>> > Otherwise just let the code handling the undef deal with the ARM/Thumb
>> > difference. For SVC, it makes sense to have different offsets as we
>> > always return to the next instruction.
>>
>> I think it just needs better documentation.
>>
>> Having been through all this, there _are_ bugs lurking in the code exactly
>> because of this randomness with what PC value is means what.
>>
>> When the VFP support code tests the state of the VFP hardware during boot,
>> it sets the VFP handler to point at vfp_testing_entry, bypassing the normal
>> VFP handling code, and executes a VFP instruction.
>>
>> If this VFP instruction faults (eg, because there is no VFP hardware
>> present or we're not permitted to use it), it could end up resuming
>> execution in the middle of the 16-bit paired instruction because
>> regs->ARM_pc points in the middle of it.
>>
>> So vfp_testing_entry should at least store r2 into regs->ARM_pc to
>> guarantee resuming at the following instruction.
>>
>> So maybe the right answer is to store r2 into regs->ARM_pc in
>> process_exception in the VFP assembly code too?
>>
>> Or maybe we should just make it unconditional that whenever we have an
>> undefined instruction exception, the regs->ARM_pc value will always be
>> set for resuming execution after the faulted instruction. ÂThat makes
>> it consistent with r2 throughout the code in every case.
>
> So... this incrementally on top of the previous patch (which I've
> reproduced below as there's a subtle comment change in there wrt IRQ
> state.)
>
> This means we have consistent state - both r2 and regs->ARM_pc always
> point to the next instruction to be executed in every case, which means
> its easy to understand and remember while reading through the code.
>
> diff -u b/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> --- b/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -499,10 +499,11 @@
>    Âblo   __und_usr_unknown
> Â3:   ldrht  r0, [r4]
>    Âadd   r2, r2, #2           Â@ r2 is PC + 2, make it PC + 4
> -    orr   r0, r0, r5, lsl #16
> +    str   r2, [sp, #S_PC]         @ it's a 2x16bit instr, update
> +    orr   r0, r0, r5, lsl #16       @ Âregs->ARM_pc
> Â Â Â Â@
> Â Â Â Â@ r0 = the two 16-bit Thumb instructions which caused the exception
> - Â Â Â @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
> + Â Â Â @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
> Â Â Â Â@ r4 = PC value for the first 16-bit Thumb instruction
> Â Â Â Â@
> Â#else

Do we need to modify the VFP entry code to avoit the store to ARM_pc?

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/