[gccsdk] UnixLib and ARMv8

Lee Noar leenoar at sky.com
Tue Mar 1 11:28:27 PST 2016


On 01/03/16 15:42, Ben Avison wrote:
> Hi folks,
>
> As you'll probably have heard, Raspberry Pi have launched a new board based
> on the ARMv8 Cortex-A53.
>
> One of the main compatibility issues remaining is that anything built on
> UnixLib is rather unlikely to work. I did a bit of investigating and found
> the problem was with the use of SWP in __pthread_disable_ints in
> libunixlib/pthread/_ints.s (although the lack of pushing a stack frame
> means that blame will be attributed elsewhere in backtraces). There are a
> couple of other instances of SWP elsewhere in UnixLib.
>
> Now, we're now living in a world where there is no one simple code sequence
> which can do atomic operations from USR mode across all CPUs from ARMv2(a)
> to ARMv8. A crude solution would be to replace
>
>      LDR    a1, .L0            @=__ul_global
>   PICEQ "LDR    a1, [a2, a1]"
>      ADD    a1, a1, #GBL_PTH_WORKSEMAPHORE
>      MOV    a3, #1
>      SWP    a2, a3, [a1]
>      @ From this point onwards we will not be interrupted by the callback
>      ADD    a2, a2, #1
>      STR    a2, [a1]
>      MOV    pc, lr
>
> with something like
>
>      LDR    a1, .L0            @=__ul_global
>   PICEQ "LDR    a1, [a2, a1]"
>      ADD    a3, a1, #GBL_PTH_WORKSEMAPHORE
>          MOV     a1, #0
>          SWI     XOS_ReadPlatformFeatures
>          MOVVS   a1, #0
>          TST     a1, #1<<12  @ does the CPU support LDREX?
>          BNE     1f
>          @ SWP version
>          MOV     a1, #1
>          SWP     a2, a1, [a3]
>      @ From this point onwards we will not be interrupted by the callback
>          ADD     a2, a2, #1
>          STR     a2, [a3]
>      MOV    pc, lr
> 1:      @ LDREX version
>          LDREX   a2, [a3]
>          ADD     a2, a2, #1
>          STREX   a1, a2, [a3]
>          TEQ     a1, #1
>          BEQ     1b
>      MOV    pc, lr
>
> and something similar for the other instances of SWP. However, I can't help
> thinking it would be neater to do the ReadPlatformFeatures once somewhere
> very early on in library initialisation and store the result in library
> static data somewhere. This is where I suspect my lack of knowledge of
> UnixLib internals means that I expect someone more familiar with it could
> knock up a solution far quicker - so, any takers?

Yes, I'll have a go when I get a chance. Thanks for the sample code,
that should make it easier.

Lee.





More information about the gcc mailing list