Difference between AOT generated for gnu and eabi target ABI

[FractalGiraffe]

In our pipeline, we build AOT files for both gnu and eabi target ABI's. However, we think we can simplify our pipeline by just building for one of them, as the generated AOT should be the same for both.

Generally, 'gnu' and 'eabi' distinguish the existence of an operating system and primarily indicate C standard library ABI. They also distinguish the sizes of some data types, like wchar_t, but that's relevant for binary compatibility, which is not an issue in our case. A C compiler may generate different function calls depending on what it believes is available above and beyond the Standard C library. A toolchain for an EABI, or bare-metal ABI, may assume a different C library (e.g. newlib or even no C library) to the GNU Linux C ABI (for which it assumes glibc). We generate AOT after we build WebAssembly with wasi-libc, so C standard library ABI is irrelevant when building AOT.

What's the difference between using gnu and eabi on generated AOT? Can you confirm we can simplify our pipeline?

Many thanks.

[wenyongh]

Hi, I have no idea about the difference between the AOT files generated for gnu and eabi either, it seems that even for eabi, the generated machine code is different when using arm-none-eabi and armv7a-none-eabi, see:
https://clang.llvm.org/docs/CrossCompilation.html
Maybe you can refer to more llvm documents.

I think here there should be no issue when an AOT function calls another AOT function as long as they uses the same abi. The issue is that callings between runtime and AOT code and runtime should have better be compiled with same abi used for AOT code: after relocation, the AOT code can directly call runtime symbols (see aot_reloc.h) and native APIs (e.g. libc-wasi), and runtime calls AOT code through asm code (see core/iwasm/common/arch/invokeNative_xxx.s) or quick aot entries (see quick_aot_entries in wasm_native.c).