I've created this Issue because Xous is now unable to build. There are several factors at play:

• unwinding now fails on nightly due to codegen #[naked] functions using global asm #128004 requiring .cfi_startproc and .cfi_endproc on all functions
• unwinding depends on #[cfg(target_feature)] which doesn't work in --release mode on RISC-V
• It's unclear whether codegen #[naked] functions using global asm #128004 is a regression or working as-designed

unwinding depends on #[cfg(target_feature)] which doesn't work in --release mode on RISC-V

hm. that should not be the case, to my knowledge? can you elaborate?

Sure.

#![feature(naked_functions)]

#[naked]
pub extern "C-unwind" fn example() {
    #[cfg(target_feature = "d")]
    unsafe {
        core::arch::naked_asm!("fsd fs0, 0x140(sp)");
    }
}

If you build this with cargo +nightly build --target riscv64gc-unknown-linux-gnu --release it fails with the following error:

error: <inline asm>:6:1: instruction requires the following: 'D' (Double-Precision Floating-Point)
fsd fs0, 0x140(sp)
^

Even though it's gated by the d flag that should only be active when the d target feature is present.

Amanieu said on the PR that this is intended behavior, so requiring CFI directives iss not an accidental regression. It will need to be fixed in unwinding.

Reproducing @Amanieu's comments on the PR here:

These directives need to be provided by the assembly author. It is up to them to declare that the naked function has valid unwind info.

[ ... ]

The previous behavior was actually context-dependent: the compiler may or may not insert cfi_startproc depending on various factors such as whether the panic mode is unwind or abort, whether unwind info is force-enabled, etc.

This makes writing code that uses CFI directives quite brittle and it's a problem I've hit before in libfringe (the predecessor of corosensei). It's much better to let users provide .cfi_startproc when they are providing unwind info for a naked function.

Unmarking this as a regression for the time being.
@rustbot label -regression-from-stable-to-nightly

If you build this with cargo +nightly build --target riscv64gc-unknown-linux-gnu --release it fails with the following error:

@xobs Hm. So, the riscv64gc target should have the "d" feature enabled, because "g" includes "d", thus the assembly should be instantiated, and is. The problem isn't with the cfg(target_feature)... that's purely handled in Rust syntax, and the error you are getting is from LLVM. It is something more subtle which causes us to not communicate to LLVM the function context has the feature.

I marked it as a regression because it worked with nightly-2024-12-12 but fails with nightly-2024-12-13:

cat > test.rs <<EOF
#![feature(naked_functions)]

#[naked]
pub extern "C-unwind" fn example() {
    #[cfg(target_feature = "d")]
    unsafe {
        core::arch::naked_asm!("fsd fs0, 0x140(sp)");
    }
}
EOF

echo -n "Building with 2024-12-12: "
rustc +nightly-2024-12-12 --target riscv64gc-unknown-linux-gnu --crate-type lib -O test.rs
echo "Done"
echo -n "Building with 2024-12-13: "
rustc +nightly-2024-12-13 --target riscv64gc-unknown-linux-gnu --crate-type lib -O test.rs

This produces:

Building with 2024-12-12: Done
Building with 2024-12-13: error: <inline asm>:6:1: instruction requires the following: 'D' (Double-Precision Floating-Point)
fsd fs0, 0x140(sp)
^

What are my options to fix the build for this target? I cannot build unwinding which is a prerequisite, due to #80608.

You can work around it by wrapping the assembly code with:

".option push",
".option arch, +d",
// your asm here
".option push",

Thank you for that suggestion. That does work, and I'll submit a patch to the unwinding project to add that. It still seems like a regression to me, in the sense that it used to work but now doesn't.

I'll keep this issue open at least until Xous builds again. Once unwinding is building again I can submit a PR to libstd to bump the version number to fix the build here.

The reason it's not labelled as a regression is because we only track regressions for stable features or accidental nightly regressions. Nightly features may break, and in this case a nightly feature had expected breakage.

@xobs Marking it as a non-regression is not "this is something we don't care about"!

It's "our regression tracking tags are implicitly for the purpose of tracking things we want to actively prevent hitting the next stable/beta release". This results in the oddity of "we would like your target to be fixed as soon as possible but we aren't too worried if the next stable release can't build it because as far as we're concerned only specific nightly releases can".