We can't have HWASAN enabled in these resolvers because they
may be called before HWASAN is initialized.
We were previously getting away with HWASAN being enabled on these
functions because ANDROID_EXPERIMENTAL_MTE was not defined, which
let the compiler simplify away any HWASAN instrumentation in the
resolvers. But with this build flag enabled (which is currently the
case in FVP, and eventually everywhere once the MTE kernel patches
land) the resolvers end up containing an HWASAN instrumented load of
the _hwcap2 field.
Bug: 135772972
Change-Id: Iac79d02ddc81630c955e107eb7f78389aeb33879
As it turns out, our "generic" arm64 implementations of certain string.h
functions are not actually generic, since they will eagerly read memory
possibly outside of the bounds of an MTE granule, which may lead to a segfault
on MTE-enabled hardware. Therefore, move the implementations into a "default"
directory and use ifuncs to select between them and a new set of "mte"
implementations, conditional on whether the hardware and kernel support MTE.
The MTE implementations are currently naive implementations written in C
but will later be replaced with a set of optimized assembly implementations.
Bug: 135772972
Change-Id: Ife37c4e0e6fd60ff20a34594cc09c541af4d1dd7
We're going to have to add ifuncs to libm, and there will be some SVE
ones for arm64 soon too, so let's start sharing the absolute minimum...
Test: builds
Change-Id: Idbb9dd9477291ed3c15dc3902f65e593b766dfb9
