may need `#pragma GCC optimize ("no-devirtualize")` before including headers to avoid undefined references

[Mis012]

the following linker errors popped up when I was trying to compile stuff (using the shared library produced with the meson patch):

/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()'
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::EnsureEmitPoolsFor(unsigned long)'
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::BlockPools()'

these are not exported by the .so:

> nm -C /usr/local/lib/libvixl.so | grep ReleasePools
00000000001d5d70 t vixl::aarch32::MacroAssembler::ReleasePools()
000000000027b680 t vixl::aarch64::MacroAssembler::ReleasePools()
00000000001d5d80 t non-virtual thunk to vixl::aarch32::MacroAssembler::ReleasePools()
000000000027b6b0 t non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()

but maybe they're supposed to be duplicated locally?
it appears they are for the aarch32 version...

> nm -C out/host/linux-x86/lib64/libart-compiler.so | grep ReleasePools
0000000000174c40 W vixl::aarch32::MacroAssembler::ReleasePools()
0000000000174c50 W non-virtual thunk to vixl::aarch32::MacroAssembler::ReleasePools()
                 U non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()

This can be "solved" by not allowing gcc to devirtualize these calls, at which point there is nothing to link and everything is fine.
I wasn't able to get gcc to devirtualize these in a small, self-contained example, but hopefully it's reproducible in https://gitlab.com/android_translation_layer/art_standalone/-/blob/e67c821e/art/compiler/utils/arm64/assembler_arm64.h#L58 (linked here the workaround that would need to be removed to reproduce the issue) not just with my setup (though the setup in question is an alpine aarch64 chroot so it should probably be possible to replicate that in the worst case)

I guess this might be an issue with GCC rather than with vixl, but I don't want to claim a compiler bug if I don't even fully understand how is the code supposed to compile

[mmc28a]

I think those Pools methods need to be exported, as they allow the user of the Macroassembler to prevent literal pools (constants) appearing in the instruction stream where they don't want them, eg. in sequences of instructions that need to be predictable for code size or patching reasons.

However, I'm not sure whether the problem lies in VIXL or the toolchain. Are you able to build with clang to see if it happens there?

[Mis012]

well, I wasn't able to reproduce this with a minimal example, so even if clang worked that could easily be due to chance... It seems the right combination of inlining and devirtualization needs to happen for this issue to manifest.