Repository navigation
AAPCS ABI is accepted for x86 target #57182
Description
Activity
- addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.A-target-specsArea: Compile-target specificationsArea: Compile-target specifications
on Dec 28, 2018 Compiling
extern "aapcs"on aarch64 will explode in LLVM withLLVM ERROR: Unsupported calling convention..- addedC-bugCategory: This is a bug.Category: This is a bug.A-FFIArea: Foreign function interface (FFI)Area: Foreign function interface (FFI)I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
on Oct 16, 2019 I ran into these same issues in #65443 .
One thing that I mentioned there, that is not mentioned here, is that because these errors can happen on stable safe Rust code, this is actually a soundness bug (safe Rust code has UB). Note also that for some ABIs, like
stdcall, we don't error on tier-1 targets.I feel that to avoid this issue in the future we should rather prefer a whitelist of ABIs, rather than a blacklist, and by default put no ABIs, so that the compilation fails until the ABI list is properly populated for the target.
I agree. There are some ABIs that the reference says are available on all targets (e.g.
"C","system","Rust", etc.) but except for those, each target should have a white-list that explicitly allows using an ABI on the target.- added a commit that references this issue
on Jul 6, 2021 - added a commit that references this issue
on Jul 6, 2021
Currently the following code compiles fine when targetting x86_64.
This code is non-sensical because AAPCS calling convention is only defined for ARM. An example of non-sensical ABI being disallowed is
when compiling with
--target=armv7-unknown-linux-gnueabihfwhich fails with:Targets should be reviewed for such nonsensical ABIs and their blacklists updated. I feel that to avoid this issue in the future we should rather prefer a whitelist of ABIs, rather than a blacklist, and by default put no ABIs, so that the compilation fails until the ABI list is properly populated for the target.