RFC on low level features #55
Conversation
| Provide an attribute that would allow to generate a naked function, without | ||
| stack guard prologue, common function prologue and epilogue. The only statement | ||
| that could be safely used in naked function is `asm!` that doesn't modify | ||
| operands (alternatively, naked functions are always considered _unsafe_). |
There was a problem hiding this comment.
Would this be addressed by allowing something like
asm!("
isr_handler:
...
")as a freestanding statement?
There was a problem hiding this comment.
Partially. I'm not sure there are absolutely no valid cases to have a naked function with a mangled name.
There was a problem hiding this comment.
Also, this statement would be a better fit for "Pure assembly functions" below. Naked function still generates a "return-from-function" statement.
There was a problem hiding this comment.
@huonw: No. Currently, the workaround is not that simple. This statement must be reachable from Rust code so that it is not recognized as dead code and optimized away.
I believe an appropriate ABI string should be supported. (unsafe could be implied by extern "naked", and extern "ABI" unsafe fn can't be declared as per rust-lang/rust#10025)
pub extern "naked" unsafe fn isr_handler() { // alternatively extern "bare"
asm!("mrs r0, psp
stmdb r0!, {r4-r11}
msr psp, r0" :::: "volatile");
switch_stack();
}There was a problem hiding this comment.
Erm, why couldn't we just make any freestanding asm! "hardcoded" to be reachable?
Presumably the programmer didn't accidentally throw it there, and approximately knows what they're doing if they're writing raw functions in asm, so the compiler can just trust them and assume it's being used & hence is reachable.
There was a problem hiding this comment.
+1 to ABI string approach, looks more elegant (extern "bare" would be the second case, if rust ends up supporting both).
There was a problem hiding this comment.
why couldn't we just make any freestanding asm! "hardcoded" to be reachable
would rust parse the assembly as well? Where would dangling instructions end up?
fn test() {
...
}
asm!("
bl test // <- this instruction is not referenced by any name, still a valid assembly.
test2:
mov r0, 0
bl test
" :::: "volatile");There was a problem hiding this comment.
It wouldn't make sense for asm! statements that are not volatile. Either way, the programmer could put it somewhere in an unused function, making the compiler generate lots of dead code.
There was a problem hiding this comment.
would rust parse the assembly as well?
Don't know, probably not; e.g., gcc just throws it all (essentially) verbatim into the final output.
There was a problem hiding this comment.
It wouldn't make sense for asm! statements that are not volatile
Totally agree with that, but it's a bit out of scope of this RFC. Or should I add it here as well?
gcc just throws it all (essentially) verbatim into the final output
That's the problem of top-level asm!. I'm not sure what is the scope of the statement — is it the translation unit itself? What section is it going to end up in, if rust switches to "-ffunction-sections"?
Re-using the function syntax provides answers for all these questions.
|
So far we've resisted exposing platform-specific linkage options, besides the limited ability to declare weak extern statics. If we were to pursue that I think I would want a more comprehensive proposal. Naked functions clearly have some use but there is a workaround of just writing it in assembly. My inclination is to hold off on adding these sort of special cases. |
|
Closing per my previously-stated rationale. |
No description provided.