-
-
Notifications
You must be signed in to change notification settings - Fork 15k
AArch64 register X18 is reserved for a platform register on VxWorks #135166
Copy link
Copy link
Closed
Labels
A-target-specsArea: Compile-target specificationsArea: Compile-target specificationsC-bugCategory: This is a bug.Category: This is a bug.O-vxworksTarget: when they made us, they called us Curiosity, and Spirit, and told us to tell you helloTarget: when they made us, they called us Curiosity, and Spirit, and told us to tell you helloT-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.
Metadata
Metadata
Assignees
Labels
A-target-specsArea: Compile-target specificationsArea: Compile-target specificationsC-bugCategory: This is a bug.Category: This is a bug.O-vxworksTarget: when they made us, they called us Curiosity, and Spirit, and told us to tell you helloTarget: when they made us, they called us Curiosity, and Spirit, and told us to tell you helloT-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.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Hi,
I'm building the 1.77.2 toolchain with
aarch64-wrs-vxworksat work and I noticed strange behavior when running library tests, most notably some references being mysteriously set to garbage values like0x0or0x10, causing segfaults. After investigation, it turns out thatrustcwas generating code using the X18/R18 register.The VxWorks ARM Architecture Guide states:
This is a bit vague, but there isn't more details and I'm not a VxWorks expert, but from what I can see the register seems to be used to store some kind of flag. This occurence is non deterministic, so it's hard to debug and observe what's going on, and it requires to build an executable that's complex enough to make the register allocator use X18.
AFAIK, this is the case for all versions of VxWorks 7 starting from
21.03(Sorry I can't share any links, the VxWorks documentation is proprietary).I think the Wind River (VxWorks' editor) compiler for C/C++ already reserve this register by default. GCC also does this by default since it supports VxWorks, however LLVM does not and so the aarch64-wrs-vxworks spec uses
aarch64-unknown-linux-gnuas the LLVM target.This issue does not seem to have been addressed upstream, but feel free to close it if this does not affect the newest version of Rust.
The easy fix for me was to simply add
reserve-x18to the list of target features, so I can take care of the MR if this is deemed reasonable.Pinging @biabbas since they're listed as the maintainer for VxWorks target on the platform support page. 😄