Problem noted in: qt4-x11_4.6.0~rc1-1ubuntu1 (lucid)
There are two problems here:
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.
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.
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.
Possibly we should add a new src/arch/corelib/qatomic_armv7.h, using a copy of qatomic_armv6.h or qatomic_avr32.h (see below) as a starting point; -arch armv7 could be passed to configure by the build rules.
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)
The qatomic_avr32.h header seems to be based on the intrinsics and may be useful as a template.
The qatomic_ia64.h header's calls to __memory_barrier() may indicate the appropriate places where an additional explicit barrier is needed.
If it is not possible to use the GCC intrinsics, a dmb instruction should be added before and after each ldrex...strex sequence where the API semantics of the atomic operations qt is trying to implement require it.
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.
Apart from the atomics, these look like optimisation opportunities and some relatively harmless minor things, but I haven't investigated in much detail yet.