Skip to content

AArch64 register X18 is reserved for a platform register on VxWorks #135166

Closed
@tekbar11

Description

@tekbar11

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. 😄

Activity

added
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Jan 6, 2025
added
O-vxworksTarget: when they made us, they called us Curiosity, and Spirit, and told us to tell you hello
on Jan 6, 2025
workingjubilee

workingjubilee commented on Jan 6, 2025

@workingjubilee
Member

Yes, adding that implicitly seems good.

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
and removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Jan 6, 2025
biabbas

biabbas commented on Jan 7, 2025

@biabbas
Contributor

@tekbar11
Rustc would invoke windriver-c++ compiler internally, and wr-c++ would add this flag. But I think adding this to the target spec features would be good.

Edit:
wr-c++ is invoked as linker, so adding this flag to target spec seems necessary.

added a commit that references this issue on Jan 8, 2025

Rollup merge of rust-lang#135184 - biabbas:reserve_18_aarch64, r=work…

bed5a90
added a commit that references this issue on Jan 8, 2025

Rollup merge of rust-lang#135184 - biabbas:reserve_18_aarch64, r=work…

45250f3
added a commit that references this issue on Jan 8, 2025
b485c00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-target-specsArea: Compile-target specificationsC-bugCategory: This is a bug.O-vxworksTarget: 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.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @tekbar11@jieyouxu@workingjubilee@rustbot@biabbas

      Issue actions

        AArch64 register X18 is reserved for a platform register on VxWorks · Issue #135166 · rust-lang/rust