Closed TemptorSent closed 4 years ago
@Ericson2314, thought I'd mention you because this seems like something that would interest you.
One thing I want to be careful about is not having ABIs overlap with CPUs that can run code compiled for a different CPU. take x86 and x86_64; the latter can run the former, but it isn't really a distinct x86_64 ABI, in that case it's just that x86_64 can run x86 code natively. x32 is different though, you really need an x86_64 compatible CPU it really is two different ABIs for the same hardware.
Yes the function that decides whether an exe wrapper is needed already says if you can run x86_64, you can run x86_32. @matthewbaur was inspired by that to add a similar relation (two arg function that returns bool is a (decidable) binary relation) to Nixpkgs, were we already tracked the abi. Now we can influence back in the other direction, and have meson mimick Nixpkgs.
I would provide links, but I am on my phone.
Closed in favor of #6361
Currently, the machine information holds the processor family and processor, but there is no way to specify the ABI to use for the CPU, nor is there a means of specifying the FPU ABI.
For example, on x86_64, we can use the 32 bit, 64 bit, or x32 ABIs for the CPU (-m32, -m64, -mx32), and FP ABI can be 387, SSE, or a combination (-mfpmath=387, -mfpmath=sse, -mfpmath=both) (https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/x86-Options.html)
The situation on ARM is much more complex, with multiple ABIs for both CPU and FPU. 64 bit arm chips can run 16 (thumb), 32, and 64 bit code. Arm chips can be bi-endian, support multiple FP ABIs, including -mfloat-abi=soft -mfloat-abi=softfp, and -mfloat-abi=hard, and have a multitude of optional CPU features: (See https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Options.html#aarch64-feature-modifiers for examples)
MIPS, RISCV, and other targets have similar complexity of options.
Adding the ability to set the ABI and related options directly in the machine information definition in cross and native files would greatly simplify both cross-compile and multilib builds and reduce the frequency of incompatible linkage attempts due to ABI mismatch.