Naked functions

Jack Applegame japplegame at gmail.com
Fri Jul 27 19:23:55 UTC 2018


On Friday, 27 July 2018 at 17:53:51 UTC, kinke wrote:
> On Friday, 27 July 2018 at 10:11:03 UTC, Jack Applegame wrote:
>> There is one strange thing.
>> Should  the compiler to insert the return command for naked 
>> functions?
>> I suppose it shouldn't.
>>
>> [...]
>>
>> Looks like LDC removes the prologue/epilogue, but not 
>> completely, leaving the return from function.
>
> In this case I'd think it has to, you're even using an explicit 
> return statement. I'm not familiar with the ARM calling 
> convention wrt. call/return, but gcc emitting no return seems 
> very strange (where is it supposed to continue after the add 
> instruction? the next function in the final binary?!). Did you 
> test that it actually works as intended?
>
> I updated the PR yesterday, so that LDC's pro-/epilogue is 
> excluded too, which allows the usage of params (not just in 
> some cases like yours together with -O). [Your sample doesn't 
> work anymore now, crashing the compiler, as it now requires 
> __asm() and/or inlineIR() to work with params.]
>
> AFAIK, a return is required as we go through LLVM IR and not 
> directly to the assembler (which for example allows you to 
> write the function body in LLVM IR). Yesterday's variant 
> probably crashes if there's no explicit return (e.g., with 
> __asm() and a naked function returning void).

My example is incorrect.
Actually, GCC documentation recommends to use only basic assembly 
in naked functions and Clang completely disallows the use of 
anything other than asm statement. But both remove the return 
instruction.
Compare:
https://godbolt.org/g/yVzpPx
https://godbolt.org/g/fe9pNY


> I take it this is just a toy example for gcc/LDC comparison, or 
> do you really need to omit a return instruction in real-world 
> code?

I'm trying to write a simple kernel with multithreading support 
on bare metal (Cortex-M3). In the context switching function, the 
compiler-inserted return is unnecessary, but not a problem.


More information about the digitalmars-d-ldc mailing list