On Fri, 10 Jun 2011, David Gilbert wrote:
On 25 May 2011 04:45, Nicolas Pitre nicolas.pitre@linaro.org wrote:
<snip>
FWIW, here's what the kernel part might look like, i.e. for compatibility with pre ARMv6k systems (beware, only compile tested):
<snip>
Hi Nicolas, I've just about got a set of gcc backend changes working for the inline case and plan on attacking libgcc next week.
What are your intentions for that code that you sent in this message - do you intend to finish it off and upstream it or were you wanting me to do that as part of this task?
I'll refine it and push it upstream.
If you're doing it could you confirm the interface to work to.
Here it goes:
* Reference prototype: * * int __kernel_cmpxchgd64(const int64_t *oldval, * const int64_t *newval, * volatile int64_t *ptr); * * Input: * * r0 = pointer to oldval * r1 = pointer to newval * r2 = pointer to target value * lr = return address * * Output: * * r0 = returned value (zero or non-zero) * C flag = set if r0 == 0, clear if r0 != 0 * * Clobbered: * * r3, condition flags * * Definition and user space usage example: * * typedef int (__kernel_cmpxchg64_t)(const int64_t *oldval, * const int64_t *newval, * volatile int64_t *ptr); * #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *)0xffff0f60) * * Atomically store *newval in *ptr if *ptr is equal to *oldval for user space. * Return zero if *ptr was changed or non-zero if no exchange happened. * The C flag is also set if *ptr was changed to allow for assembly * optimization in the calling code. * * Notes: * * - This routine already includes memory barriers as needed. * * - Due to the length of some sequences, this spans 2 regular kuser * "slots" so 0xffff0f80 is not used as a valid entry point. * * - This call is valid only if __kernel_helper_version >= 5.
Of course, as discussed, this would be preferable if the interface in libgcc was in a separate object file so any reference to it would also bring in a global constructor from which the __kernel_helper_version value could be verified in order to prevent usage of this interface on kernels that lack it.
Also, do you think there should be a halfword and byte interface as well, given that halfword and byte ldrex implementations aren't available on older ARMs, or expect user space to do a bit of mask fiddling with the 32bit ones?
It is indeed better if user space deals with it using the 32-bit interface. I'd prefer adding new kernel helpers only when absolutely required.
Nicolas