[Qtwebengine] Qt5.7 QtWebEngine and ARMv8 (RPi3)

[Ville Voipio]

QtWebEngine (and Chromium) seem to be slightly challenging to compile with ARMv8 (32-bit) settings, more specifically for Cortex A53.

The mkspec file (mkspecs/devices/linux-rpi3-g++/qmake.conf) defines the processor compile flags as:

  QMAKE_CFLAGS = -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8

This seems to be the correct combination for ARM A53. Compiling QtCore gives no complaints, but there are at least three different problems with QtWebEngine (two of them fatal from the build point of view).

1. specifying arm-version="8" will crash the compilation due to unknown architecture errors

2. the build system does not recognize crypto-neon-fp-armv8 as a NEON capable architecture (this will crash the linking complaining the lack of sk_cpu_arm_has_neon(), see SkUtilsArm.h in skia).

3. there are a lot of warnings about deprecated IT blocks in ARMv8


I was able to compile QtWebEngine by patching qtwebengine/src/core/gyp_run.pro, but my patches are very ugly and do not really address the underlying problems.


Problem #1: arm_version="8"

The first problem is fixed by a small addition to gyp_run.pro:

  lessThan(MARMV, 6): error("$MARCH architecture is not supported")
  else: equals(MARMV, 7): GYP_CONFIG += arm_version=\"$MARMV\"
  else: GYP_CONFIG += arm_version=\"7\"

Now ARMv8 (and higher) will set arm_version="7", whereas the original code set arm_version="8". (This should really be solved deeper down, and this is certainly not future-proof.)


Problem #2: NEON support not detected

The NEON problem is caused by the NEON detection in gyp_run.pro. The code can be patched by adding one more condition (the last one):

  contains(MFPU, "neon")|contains(MFPU, "neon-vfpv4")|contains(MFPU, "crypto-neon-fp-armv8")

Now the FPU flag crypto-neon-fp-armv8 is recognized as a NEON capable processor. However, the detection method is still a bit flaky, as there are a number of other strings which should qualify here (as per the compiler ARM-specific flag descriptions).

This problem could and possibly should be fixed in some other places, as well. ARMv8 processors are always NEON-capable, and thus the following lines in skia_common.gypi seem to be wrong:

  [ 'target_arch == "arm" and arm_version >= 7 and arm_neon == 0 and arm_neon_optional == 1’, { 
    'defines': [
        'SK_ARM_HAS_OPTIONAL_NEON',
    ],
  }],
],

All in all, it does not seem to be completely clear where the problem should really be solved.


Problem #3: Deprecated IT block warnings

ARMv8 (in 32-bit mode) will accept any binary which is acceptable by ARMv7, so there cannot be any instructions which would not work. The warnings are about deprecated (not eliminated) machine code instructions. However, there are hundreds (thousands?) of these warnings during compilation, and possibly something should be done. The deprecated code is most probably inline assembly code, as the C compiler should not emit deprecated code.


Questions

Now we come to the tricky part. Everything compiles, but only with ugly tricks. So:

* Is there anything Qt can or should do about this? Or should these just be reported to the Chromum people?

* Should the architecture be set to ARMv7 even with RPi3 until the Chromium code is fixed?

* If yes, is there a way to do it only for QtWebEngine (instead of the complete Qt distribution)

* Alternatively, should we just decide that all RPi3 code is better compiled with RPi2 settings (this will leave some optimizations aside) and change the mkspec file accordingly?



TIA,

- Ville