RFC 1201 amendments: Naked function corrections

[alistair23]

This PR does two things both related to naked functions. Check the individual commits for more details.

[fintelia]

My personal preference is for option 2, but only for for extern "C" functions. Calling naked functions with arguments from other Rust code otherwise becomes much harder. I'm not actually sure how it could work. Combining the naked function definition with a separate extern declaration containing the real argument list seems hypothetically possible but doesn't really seem like an improvement?

If we're tweaking the rules for naked functions, we should probably also say that the compiler is no longer allowed to inline them.

[alistair23]

My personal preference is for option 2, but only for for extern "C" functions.

Is is possible to pass that information down to LLVM to have it handle that?

Calling naked functions with arguments from other Rust code otherwise becomes much harder.

Yes, this will be difficult to do, but from my understanding of the current RFC that is discouraged anyway.

Combining the naked function definition with a separate extern declaration containing the real argument list seems hypothetically possible but doesn't really seem like an improvement?

Yeah, I guess that is possible.

If we're tweaking the rules for naked functions, we should probably also say that the compiler is no longer allowed to inline them.

Good idea, I'll add an extra commit to this PR with that.

[alistair23]

I have added a change about inlining naked functions

[comex]

Naked functions with arguments are useful. For instance, to do a system call:

#[naked]
pub unsafe fn stat(buf: *const u8, buf: *const u8) {
    asm!("mov $0x20000bc, %%eax; syscall");
}

I don't see a reason to ban them. At most, rustc could emit a warning until the LLVM bug has been confirmed fixed.

[alistair23]

LLVM specifically specifies:

Don't allow non-asm statements in naked functions
Don't allow asm statements to refer to parameters in naked functions.

https://reviews.llvm.org/D5183

so although it seems useful I don't think it should be supported.

[alistair23]

I am open to a warning though, which would allow people who really want to have arguments use them but discourage people from doing it.

Also, while we are changing everything should we fix the unresolved question of allowing non asm! functions? It also seems like a bad idea that LLVM doesn't support.

[alistair23]

I have updated the PR to indicate that naked functions will never be inlined as the LLVM code won't inline a naked function. This makes that information explicit.

https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CodeGenModule.cpp#L1539

[fintelia]

The current compiler is definitely willing to inline a naked function: https://rust.godbolt.org/z/n9JvSL

#![feature(naked_functions)]
#![feature(asm)]

#[naked]
extern "C" fn foo() {
    unsafe { asm!("int3") }
}

pub fn main() {
    foo();
}

Produces this assembly:

example::main:
        int3
        ret

[comex]

LLVM specifically specifies:

Don't allow non-asm statements in naked functions
Don't allow asm statements to refer to parameters in naked functions.

You don't refer to the parameters explicitly (i.e. naming then in constraints). Instead, the assembly code in the inline asm block would expect them to be in certain registers as per the platform ABI. Normally you wouldn't be allowed to assume anything about register state from an inline asm block, but the point of naked functions is that the contents of the block make up the entire body of the function; the compiler won't do any register manipulation behind your back. Or at least, it's not supposed to.

[comex]

I have updated the PR to indicate that naked functions will never be inlined as the LLVM code won't inline a naked function. This makes that information explicit.

https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CodeGenModule.cpp#L1539

The code you linked is from Clang, not LLVM proper. It sounds like rustc should be doing the same thing (adding the noinline attribute in addition to the naked attribute), but it currently isn't. :)

Edit: Which corresponds to the bug report that @fintelia linked.

[alistair23]

Ok, I'm going to drop the arguments change and do some more research. It sounds like arguments should be supported and there is a bug somewhere in the naked function handling, either in rust or LLVM.

On the other hand function arguments shouldn't be directly accessed and I think naked functions should never be inlined.

I'll update the patches with those changes.

[roblabla]

If naked functions should only have a single asm statement, and shouldn't be inlined, what's the difference between them and global_asm? It seems to me that they could be desuggared simply:

// Original:
#[naked]
pub unsafe fn stat(buf: *const u8, buf: *const u8) {
    asm!("mov $0x20000bc, %%eax; syscall");
}

// Desuggared:
global_asm! {
"""
.global mangled_stat
mangled_stat:
   mov $0x20000bc, %%eax; syscall
"""
}

extern {
    #[link_name = "mangled_stat"]
    fn stat(buf: *const u8, buf: *const u8);
}

This would sidestep the asm bug, and further enforce the rule that Naked functions must only contain a single asm call.

[comex]

There's not much difference. Indeed, naked functions may not be truly necessary to have as a feature, but some people apparently prefer them over global_asm for reasons that are not entirely clear to me. I can think of a few concrete advantages:

• Compiler handles name mangling
• Compiler handles linking (.globl may not be the right declaration, e.g. if you want a hidden visibility symbol inside a shared object)
• Can be combined with generics to create multiple variations of a function
  • but it might be better to just use assembly macros for that

[fintelia]

I think that @roblabla's example shows a couple more reasons why people prefer naked functions:

• The desuggared way to write the function is over twice as long (and is almost entirely boilerplate)
• It is rather non-obvious from any of the documentation I read that global_asm + extern block + link_name is the correct incantation. I didn't know that would work prior to reading this thread while the #[naked] annotation "just works" with minimal guessing.
• Having a separate extern block to control the signature of the function defined in the global asm block feels a lot like action at a distance.

[alistair23]

I have updated the PR to drop the argument removal requirement and to add some new ones. Let me know what you think.

[alistair23]

Thoughts on the new commits?

[Aaron1011]

This seems to suggest that you can have a naked function with parameters, but you can't use them. This seems incorrect - parameters will always have an implicit use due to the generated drop calls. Shouldn't naked functions be forbidden from taking any parameters?

[alistair23]

That was my original intention, but passing arguments still makes sense as you can reference them directly from the registers in the assembly.

[Aaron1011]

That would require rust to generate a prologue, though - which naked functions are supposed to avoid.

[roblabla]

No, it doesn't require rust to generate a prologue, it requires the ASM author to know about the calling convention (which is the case for extern C functions) and properly handle it themselves.

drop calls are a good point. I guess arguments should be !Drop?

[Aaron1011]

@roblabla: What if the calling convention requires generating a prologue? I don't think a naked fn should cause Rust to generate some weird subset of the normal ASM for a function.

Note that it's not sufficient to require arguments to be !Drop - they also must not have any drop glue (e.g. struct MyStruct(String) is !Drop but has drop glue).

I really don't see passing parameters to naked functions as being useful, or even very well-defined.

[roblabla]

Then they should be Copy - which AFAIU denies the drop glue. This is similar to the restrictions union currently have - unions may not have items that are Drop, so as an approximation they only allow Copy types.

Passing parameters to naked function that have a known ABI (such as extern "C") is well-defined - that's sort of the whole point of those ABIs. If a CC requires a prologue as part of the ABI, then it's up to the person writing the naked function to insert that prologue. This is similar to defining functions with global_asm!.

People have further shown that they are useful - for instance look at this comment.

[alistair23]

Any update on this?

[shepmaster]

Typos in the commit messages and PR title: "ammendments" -> "amendments"

[alistair23]

I have fixed the typos and rebased on master.

Any other thoughts?

[alistair23]

Just to summerise where we are:

• I think everyone is onboard with not allowing naked functions to be inlined. As the compiller can't safely change/remove the prologue and epilogue for naked functions when it inlines them inlining the naked functions could result in strange bugs.
  • This would fix: Should #[naked] functions default to #[inline(never)] ? rust#60919
• The current situation of allowing arguments and rust code in naked function does not work (Naked functions with arguments generate a prologue rust#42779). So we either need to
  • Not allow arguments
    • This then ends up being the same as global_asm so why even have naked functions?
  • Only allow asm and not reference the arguments
    • This has uses, as pointed out in a comment above (RFC 1201 amendments: Naked function corrections #2774 (comment)) and as used in libtock-rs

[alistair23]

Closing as this isn't being merged.