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

[Catalin Marinas]

On Saturday, 15 January 2011, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> On Sat, Jan 15, 2011 at 03:31:04PM +0000, Catalin Marinas wrote:
>> On 14 January 2011 17:30, Russell King - ARM Linux
>> <linux@xxxxxxxxxxxxxxxx> wrote:
>> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> > index 2b46fea..5876eec 100644
>> > --- a/arch/arm/kernel/entry-armv.S
>> > +++ b/arch/arm/kernel/entry-armv.S
>> > @@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
>> > Â Â Â Â.align Â5
>> > Â__und_usr:
>> > Â Â Â Âusr_entry
>> > -
>> > - Â Â Â @
>> > - Â Â Â @ fall through to the emulation code, which returns using r9 if
>> > - Â Â Â @ it has emulated the instruction, or the more conventional lr
>> > - Â Â Â @ if we are to treat this as a real undefined instruction
>> > Â Â Â Â@
>> > - Â Â Â @ Âr0 - instruction
>> > + Â Â Â @ The emulation code returns using r9 if it has emulated the
>> > + Â Â Â @ instruction, or the more conventional lr if we are to treat
>> > + Â Â Â @ this as a real undefined instruction
>> > Â Â Â Â@
>> >    Âadr   r9, BSYM(ret_from_exception)
>> >    Âadr   lr, BSYM(__und_usr_unknown)
>> > + Â Â Â @
>> > + Â Â Â @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
>> > + Â Â Â @ faulting instruction depending on Thumb mode.
>> > + Â Â Â @ r3 = regs->ARM_cpsr
>> > + Â Â Â @
>> >    Âtst   r3, #PSR_T_BIT         Â@ Thumb mode?
>> > -    itet  Âeq               Â@ explicit IT needed for the 1f label
>> > +    itttt  eq               Â@ explicit IT needed for the 1f label
>> >    Âsubeq  r4, r2, #4           Â@ ARM instr at LR - 4
>> > -    subne  r4, r2, #2           Â@ Thumb instr at LR - 2
>> > Â1: Â Â ldreqt Âr0, [r4]
>>
>> The itttt above should just be itt. The reveq is conditionally
>> compiled and beq doesn't necessarily need one.
>
> It's a reveq, so I thought we should cover all the instructions with
> an 'eq' conditional for thumb.

If the it instruction doesn't cover all instructions, gas generates
some more its. But in this case, for little endian, the it instruction
covers more since reveq isn't included and having the beq not last in
the block I think is unpredictable. If you really want to optimise the
big endian case not to have an additional it generated by gas, you can
write ittt so that beq is included with little endian but not with big
endian. I wouldn't bother much for an extra it anyway.

>> > Â#ifdef CONFIG_CPU_ENDIAN_BE8
>> >    Âreveq  r0, r0             Â@ little endian instruction
>> > Â#endif
>> > + Â Â Â @
>> > + Â Â Â @ r0 = 32-bit ARM instruction which caused the exception
>> > + Â Â Â @ r2 = PC value for the following instruction (:= regs->ARM_pc)
>>
>> Is r2 here always the PC value following instruction? If the Thumb
>> instruction was 32-bit, it just points in the middle of the faulting
>> instruction.
>
> Is the T bit ever zero in this case? ÂThe code here is:
>
>    Âtst   r3, #PSR_T_BIT
>    Âsubeq  r4, r2, #4
> 1: Â Â Âldreqt Âr0, [r4]
>    Âreveq  r0, r0
>    Âbeq   call_fpe

You can have the T bit set but the instruction a 32-bit Thumb in which
case r2 is in the middle of such instruction rather than the next.
Unless you only refer to the ARM mode, in which case the comment is
fine.

> So, if !T, then we subtract 4 and load the instruction (which was the
> faulting instruction). ÂSo r2 is the following instruction.
>
> Ah, maybe you're getting confused by the comment. ÂShould we put
> an 'eq' suffix on the end of each line? ;)

Maybe mention that this is ARM. I think documenting this code is
difficult anyway. I found myself not reading the comments at all when
revisiting this code :) but they may be useful for others.


-- 
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/