[Bug 490371] [NEW] Atomic operations not safe for ARMv7, Thumb-2 and multicore

Thiago Macieira 490371 at bugs.launchpad.net
Fri Nov 19 08:30:49 UTC 2010


Em Quarta-feira, 17 de Novembro de 2010, às 16:18:59, ext Launchpad Bug 
Tracker escreveu:
> 1) in configure, the build architecture baseline is detected using
> `uname -r`: this just gives "armel", which does not work for determining
> whether the baseline is armv6 or armv7 or whatever.  There are some
> specific files for armv6, but these are not used because configure
> defines QT_ARCH_ARM instead of QT_ARCH_ARMV6.
> 
> It may make sense for the ubuntu build rules to pass an explicit -arch
> option to configure.

Fixed in Qt 4.8. See patchset:

f293b98 Silence preprocessor warnings about __TARGET_ARCH_ARM not being 
defined.
c7bf2d7 Fixed compile for symbian.
dc8d096 Compile when detecting ARMv5
2c73f55 Compile when detecting ARMv5
82b4fff Add support for ARMv7 atomic operations
7be2c58 Merge the armv6 and arm architectures
1c0b3237 Copy src/corelib/arch/qatomic_arm.h to 
src/corelib/arch/qatomic_armv5.h
a0f69c0 Move symbian specific qatomic_generic_armv6.cpp

Qt now has one "ARM" architecture and determines which instructions to use 
depending on the compiler arguments and #defines.

> 2) The "generic arm" atomics in src/arch/corelib/qatomic_arm.h use the
> swp and swpb instructions.  This is incompatible with Thumb-2 and will
> not be multicore-safe, especially for armv7.

These instructions shouldn't be used at all. They were used for OABI only. In 
EABI, code should be generated to kernel-provided atomics. Also, with the 
patchset above, this shouldn't be used in v6 or v7 builds at all.

> 3) The armv6 atomics in src/arch/corelib/qatomic_armv6.h (not currently
> used because of the behaviour of configure; see (1)) use the new
> ldrex/strex instructions appropriately, but the required memory barriers
> for safe operation on multicore platforms are missing.

Fixed in Qt 4.8 already:
82b4fff Add support for ARMv7 atomic operations

> If at all possible, this new header should be ported to use the GCC atomic
> intrinsics: see https://wiki.ubuntu.com/ARM/Thumb2 and
> http://refspecs.freestandards.org/elf/IA64-SysV-psABI.pdf section 7.4
> (Synchronization Primitives)

Aside from __sync_lock_release and __sync_lock_test_and_set, all barriers 
provided by this psABI are full barriers (ordered, in Qt terms).

I don't know why Intel didn't define the full set, since that was created for 
the IA-64, which is one of the few platforms where different barriers are 
possible. Qt does implement the full set for both IA-64 and ARMv7, so we're 
not going to switch to __sync_* until they support the full set.

> Searching for other possibly arm/armv6 specific files, if would be a good
> idea to review the following for implications. See
> https://wiki.ubuntu.com/ARM/Thumb2 for details of things to check for.

These files should be:

src/3rdparty/pixman/pixman-arm-neon-asm.S
src/3rdparty/pixman/pixman-arm-neon-asm.h

src/corelib/tools/qstring.cpp
src/gui/image/qimage_neon.cpp
src/gui/painting/qdrawhelper_neon.cpp
src/gui/painting/qdrawhelper_neon_asm.S
src/gui/painting/qdrawhelper_neon_p.h

-- 
Thiago Macieira - thiago.macieira (AT) nokia.com
  Senior Product Manager - Nokia, Qt Development Frameworks
     Sandakerveien 116, NO-0402 Oslo, Norway

-- 
Atomic operations not safe for ARMv7,Thumb-2 and multicore
https://bugs.launchpad.net/bugs/490371
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to qt4-x11 in ubuntu.




More information about the kubuntu-bugs mailing list