Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch

[Benjamin ZORES <benjamin.zores@domain.hid>]

Philippe Gerum a écrit :
>> FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09 
>> (latest) and Xenomai 2.3.4 (latest).
>>     
read Xenomai 2.4.4 here, of course ...
>
> See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part that does the
> actual stack switching.
>
> Note that this code is obfuscated by the fact that we have to handle so-called
> "hybrid" switching, between Xenomai kernel threads (which do not rely on a
> task_struct), and Linux tasks (Xenomai userland, Linux kthreads, or regular
> userland Linux). Fortunately, what is saved on the stack in any case is easy to
> find out.
>   
Ok, I've dig a bit more at sources and found out something strange.

In xenomai arch/powerpc/xenomai/switch_32.S in rthal_thread_switch() we 
have:

********
#ifdef CONFIG_SMP
    sync
#endif /* CONFIG_SMP */

    lwz    r1,KSP(r4)    /* Load new stack pointer */

    mr    r3,r2
    lwz    r0,PGDIR(r4)
        cmpwi   r0, 0
        beq-    same_current

    tophys(r0,r4)
    CLR_TOP32(r0)
    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */
    addi    r2,r4,-THREAD    /* Update current */

same_current:
**********

While, in arch/powerpc/kernel/entry_32.S in _switch() we have:

**********
#ifdef CONFIG_SMP
    /* We need a sync somewhere here to make sure that if the
     * previous task gets rescheduled on another CPU, it sees all
     * stores it has performed on this one.
     */
    sync
#endif /* CONFIG_SMP */

    tophys(r0,r4)
    CLR_TOP32(r0)
    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */
    lwz    r1,KSP(r4)    /* Load new stack pointer */

    /* save the old current 'last' for return value */
    mr    r3,r2
    addi    r2,r4,-THREAD    /* Update current */
************

As we can see, the code differs from kernel, as

    tophys(r0,r4)
    CLR_TOP32(r0)
    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */

is done _before_ loading new stack pointer in kernel and _after_ doing 
so in xenomai.

Is there a good reason for that or is this unintended ??

Ben