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
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.
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 arch/qatomic_ arm.h to arch/qatomic_ armv5.h generic_ armv6.cpp
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/
src/corelib/
a0f69c0 Move symbian specific qatomic_
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 /wiki.ubuntu. com/ARM/ Thumb2 and refspecs. freestandards. org/elf/ IA64-SysV- psABI.pdf section 7.4
> intrinsics: see https:/
> http://
> (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 /wiki.ubuntu. com/ARM/ Thumb2 for details of things to check for.
> idea to review the following for implications. See
> https:/
These files should be:
src/3rdparty/ pixman/ pixman- arm-neon- asm.S pixman/ pixman- arm-neon- asm.h
src/3rdparty/
src/corelib/ tools/qstring. cpp image/qimage_ neon.cpp painting/ qdrawhelper_ neon.cpp painting/ qdrawhelper_ neon_asm. S painting/ qdrawhelper_ neon_p. h
src/gui/
src/gui/
src/gui/
src/gui/
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Product Manager - Nokia, Qt Development Frameworks
Sandakerveien 116, NO-0402 Oslo, Norway