Description
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 like 0x0 or 0x10, causing segfaults. After investigation, it turns out that rustc was generating code using the X18/R18 register.
The VxWorks ARM Architecture Guide states:
The general purpose register X18 is reserved for a VxWorks platform register. User code must not use the X18 register.
Kernel and user applications must be compiled with the -ffixed-x18 compiler option (which is one of the defaults for VxWorks builds).
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. 😄