For aarch64, the output is:
adenilson@p700:~/chromium/src$ gn gen out/aarch64/
### Current cpu is: arm64 target cpu is: arm64
### Current cpu is: x64 target cpu is: arm64
### Current cpu is: arm target cpu is: arm64
Done. Made 19099 targets from 1302 files in 4813ms

With the config:
# Build arguments go here.
# See "gn args <out_dir> --list" for available build arguments.

target_os = "android"
target_cpu = "arm64"  # (default)
is_debug = true  # (default)

# Other args you may want to set:
is_component_build = true
is_clang = true
enable_incremental_javac = true  # Much faster; experimental

So it seems that we got verify what is the **target_cpu** instead of **current_cpu** for defining macros that will change the code used in zlib.

I wonder how widespread this issue is (i.e. other libs/code affected?).

Re #1, That example should only effect v8 builds, right? The rest of Chromium is probably not using that value?

Is there a place where it is set for non-v8 builds?

That rule seems to be imported by the arm build script:
https://cs.chromium.org/chromium/src/build/config/arm.gni?l=5

So, a priori, anyone importing arm.gni would potentially be affected.

It looks like this is expected. But I have no idea why.

There are 3 variables of interest: host_cpu, current_cpu, and target_cpu.
host_cpu is what you are compiling on.
target_cpu is the platform the code should run on. This might involve cross compiling like we typically do here.
current_cpu is GN-generated and expected to cause multiple compiles:
https://cs.chromium.org/chromium/src/build/config/BUILDCONFIG.gn?l=29&rcl=242b78c83ad56851fb49f0f9e2001cdeecebd935


I am not entirely sure why this is.
The v8 build file mentions that we might be running on x64 but want to emulate arm. Maybe that is why? Part of the build might involve emulating as if we were building from those other cpus?

I'm unsure really.

Will reassign to a lower priority and look on it later.