On Fri, 10 Jun 2011, David Gilbert wrote: > On 25 May 2011 04:45, Nicolas Pitre <nicolas.pi...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
