brettw@, dpranke@, scottmg@: CC-ing you because you're in //build/config/OWNERS
dpranke@, jbudorick@, phajdan.jr@, scottmg@, tansell@: CC-ing you because you're in //tools/mb/OWNERS

I've been struggling with some failures on the android_arm64_dbg_recipe bot. The bot name implies that it's doing an ARM64 build. As I'll explain below, that doesn't seem to be the case, so I'll refer to the builds produced as "arm64" builds.

//tools/mb/mb_config.pyl [1, 2, 3] reveals that the bot adds target_cpu="arm64" to gnargs (android_arm64_dbg_recipe -> android_debug_trybot_arm64 -> ['android', 'debug_trybot', 'arm64']). Of related interest, other lines in the same file [4, 5] show that android_n5x_swarming_rel is also using an "arm64" build. (android_n5x_swarming_rel -> android_release_trybot_arm64 -> 'android', 'release_trybot', 'arm64').

The ARM-specific GN configuration seems to be done in //build/config/arm.gni [6], which sets a fair amount of GN variables for current_cpu=="arm", but is much terser for current_cpu="arm64". Most interestingly, the default arm_version is set to 7 when current_cpu=="arm". This build failure [7] shows that arm_version is not defined for "arm64" builds. This build failure [8] shows that "arm64" builds end up with -march=armv7-a (search for "-march=armv7-a" in the log).

Wikipedia [9] states that ARM64 (a.k.a. AArch64) was introduced in ARMv8-A. While using Wikipedia alone as a source is unreliable, Google searches for "ARM64" and "AArch64" lead to the same conclusion. So it doesn't seem to make sense to produce 64-bit builds targeting ARMv7-A's feature set. My last build failure [8] suggests that Clang (rightfully?) removes support for 64-bit instructions when -march=armv7-a is passed in (as crc32cd is disabled).

Of related interest, result counts for current_cpu=="arm" [10] vs current_cpu == "arm64" [11] (62 vs 40) seem to indicate that most of the codebase (thinks it?) is addressing both targets.

I generally like to submit fix CLs together with bugs, but in this case I don't know enough to figure out the best place to fix the problem. It seems like we could consider renaming/documenting the "arm64" string in the build bots and current_cpu,target_cpu, or we could fix the build configuration so it targets ARMv8-A when current_cpu=="arm64". This is subtle, as I imagine that we wouldn't want to have android_n5x_swarming_rel (which is on CQ) produce actual ARM64 builds, as we'd be testing a configuration we don't actually ship.

I welcome your thoughts on this, and am happy to help with whatever the right improvement might be.


[1] https://cs.chromium.org/chromium/src/tools/mb/mb_config.pyl?l=496
[2] https://cs.chromium.org/chromium/src/tools/mb/mb_config.pyl?l=825
[3] https://cs.chromium.org/chromium/src/tools/mb/mb_config.pyl?l=1609
[4] https://cs.chromium.org/chromium/src/tools/mb/mb_config.pyl?l=512
[5] https://cs.chromium.org/chromium/src/tools/mb/mb_config.pyl?l=845
[6] https://cs.chromium.org/chromium/src/build/config/arm.gni
[7] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.android%2Fandroid_arm64_dbg_recipe%2F336825%2F%2B%2Frecipes%2Fsteps%2Fanalyze%2F0%2Fstdout
[8] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.android%2Fandroid_arm64_dbg_recipe%2F336809%2F%2B%2Frecipes%2Fsteps%2Fcompile__with_patch_%2F0%2Fstdout
[9] https://en.wikipedia.org/wiki/ARM_architecture#AArch64_features
[10] https://cs.chromium.org/search/?q=%22current_cpu+%3D%3D+%5C%22arm%5C%22%22+file:%5C.gn&sq=package:chromium&type=cs
[11] https://cs.chromium.org/search/?q=%22current_cpu+%3D%3D+%5C%22arm64%5C%22%22+file:%5C.gn&sq=package:chromium&type=cs