This naked function SIGSEGVs

[nagisa]

#![feature(naked_functions)]

#[naked]
fn naked(x: u32) -> u32 {
    x + 1
}

fn main(){
    naked(42);
}

SIGSEGVs on my system, but it only happens in builds without -O or -g flags, making it hard to debug.

[arielb1]

Naked functions that contain anything other than an asm blocks are at the very least unspecified behavior.

[nagisa]

@arielb1 I do not disagree, however the RFC does not have any such requirements, and the RFC discussion seemed to imply it “just works”.

[nagisa]

At the very least we should forbid non-single-asm-statement naked functions.

[nagisa]

cc #32408

[ranma42]

Would it make sense to allow non-single-asm-statement naked parameterless functions?
AFAICT on supported platforms it should be possible to write a naked function in pure Rust as long as:

• no parameters are passed
• no unwinding is needed

[nagisa]

Right, both of these must make rustc fail, but doesn’t currently.
Either way, this example also sigsegvs with many of the supported CCs
and with unsafe.

On Sun, 27 Mar, 2016 at 5:49 PM, Kai Noda notifications@github.com
wrote:

Defining a naked function with the default (Rust) ABI is an error,

naked functions must be declared unsafe or contain no non-unsafe
statements in the body.

These statements in RFC1201 drew my attention.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[arielb1]

@nagisa

I don't think that we should prevent random undefined uses of naked functions from compiling unless we have a good set of rules. Maybe lint against them.

[tari]

Asm-only naked functions are a very large potential footgun, mentioned as an unresolved question in the RFC since there wasn't consensus on what a reasonable approach is. Opinions tend to be split between those who are okay with the correctness of their code being at the whims of the code generator (allowing Rust code in naked functions, trading safety guarantees for improved efficiency) and those who prefer to ensure it is impossible to generate wrong code by accident.

The compromise solution is requiring the body of a naked function be unsafe (#32489), but that means (if made unsafe), I don't think the code sample in OP is a Rust bug.

---

The actual correctness of non-asm code in naked functions depends on the optimizer and code generator, which in general we cannot make any guarantees about what it will do. A rule like "no parameters allowed" is not sufficient to ensure generated code is correct. I believe the only way to properly check for implied stack allocations is to perform some kind of checking pass after codegen, which would at the least require some significant compiler complexity.

A lint against non-asm code in naked functions sounds like a reasonable approach to further help avoid foot-shooting to me.

[parched]

I've hit an issue here too. I had a naked function as the entry point to some baremetal code. The first thing the function does is set up the stack pointer with some asm! then it has some rust code with automatic variables. I expected this to work but when I had a look at the llvm-ir the alloca for the automatic variable was placed before my asm!, not after.

I have gone with the pure asm! in the naked function which branches to another function with the rust code. This is fine but it is a little annoying needing the unnecessary branch.

[npmccallum]

@nagisa This is probably fixed in this patch: #74105