AArch64 register X18 is reserved for a platform register on VxWorks #135166
Labels
A-target-specs
Area: Compile-target specifications
C-bug
Category: This is a bug.
O-vxworks
Target: when they made us, they called us Curiosity, and Spirit, and told us to tell you hello
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Hi,
I'm building the 1.77.2 toolchain with
aarch64-wrs-vxworks
at work and I noticed strange behavior when running library tests, most notably some references being mysteriously set to garbage values like0x0
or0x10
, causing segfaults. After investigation, it turns out thatrustc
was 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-gnu
as 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-x18
to 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. 😄
The text was updated successfully, but these errors were encountered: