[Added the "armv7" tag to help track ARMv7 migration issues.] Agreed, the best way to solve cases like this is to use the GCC intrinsics instead of inline asm.
The attached patch should hopefully work for this; but I haven't been able to build or test it just yet. I've tried to modify configure to check for support for the intrinsics in GCC, by doing a link test on a call to __sync_synchronize(). Assuming the support is there, this uses some code in glib/qatomic.c which uses the intrinsics instead of inline asm -- this results in a simpler implementation. I've also turned on memory barriers to make sure that the code is SMP- safe. Conveniently, the support for this was already in there; I just needed to define how to do a memory barrier and set the appropriate variable in configure. Note: 1) The GCC atomic intrinsics require linux-2.6.13 or higher. This is no problem for Ubuntu, but upstream people using old kernels may get problems, so we might want an extra configure argument to turn on my modifications, and pass it from the build rules. 2) People using old compilers won't get the benefits, and will fall back to the SWP-based code. Again, this is not a problem for Ubuntu, but may affect upstream people using older tools. If this is seen as an issue we could include some inline asm which reproduces the intrinsics' behaviour as an additional fallback, if building for -march=armv6 or above (for older architectures, SWP is the right way since nothing else existed there). ** Attachment added: "(untested) patch to implement splinlock lock and unlock for glib2.0 using GCC atomic intrinsics on armel" http://launchpadlibrarian.net/36338207/glib2.0-gatomic-arm.diff -- assembly fails to build on armel/lucid https://bugs.launchpad.net/bugs/491342 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to glib2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
