Re: naked function attribute support for Mips
On 03/05/13 16:03, Richard Sandiford wrote:
David Brown writes:
Personally, I've used "naked" when I want to write pure assembly code
and don't want extra stack frames or "return" codes. I don't want to
write stand-alone assembly files (I've written mountains of them in the
past, and hope they stay in the past). I am happier using the very nice
flexible gcc inline assembly syntax.
The full inline asm syntax, such as:
asm ("..." : "=r" (result) : "i" (100))
is specifically forbidden in naked functions, because in general GCC can
only satisfy the constraints by building its own frame:
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
the specified function does not need prologue/epilogue sequences generated by
the compiler. It is up to the programmer to provide these sequences. The
only statements that can be safely included in naked functions are
@code{asm} statements _that do not have operands_. All other statements,
including declarations of local variables, @code{if} statements, and so
forth, should be avoided.
(my emphasis). Naked functions must have a body of the form:
{
asm ("");
}
i.e. an asm with just a plain string, and no other statements or
local variables. So you don't really get any more flexibility
by using inline asms over using assembly files.
Thanks,
Richard
In practice, it is perfectly possible to have full inline assembly with
variables inside "naked" functions. It is also possible to use normal C
code - in fact this is regularly done on targets such as the AVR that
support "naked".
The limitation with "naked" is that the compiler does not generate a
stack frame. So if your code requires a stack frame, you have to do it
manually in assembly - though obviously you are almost certainly better
off using a normal non-naked function in this case. But for processors
with plenty of registers, you seldom need a stack frame - stick to the
"volatile" registers and you will be fine.
The documentation here could certainly be a lot clearer, since there is
no doubt that you can use a lot more than just simple asm statements
inside naked functions - and no doubt that it is very useful to be able
to use simple, restricted C code and advanced inline assembly. Examples
can be seen at the end of this page:
With a quick test using the AVR port (since I am familiar with it),
version 4.5.1 (a little old, but I have it on this machine), I can see
that code the requires a stack frame is generated as normal, but missing
the prologue and epilogue that actually create and destroy the stack frame.
What would be very nice is for the compiler to generate a warning or
error message if a stack frame is needed inside a "naked" function - the
compiler already has this information (in order to implement
-fomit-frame-pointer). That would make "naked" safer, and therefore
more usable.
But even without that, it is a feature that is useful on special
occasions, for people who know what they are doing.
Re: naked function attribute support for Mips
Microchip which makes the Pic32 embedded processor (Mips32) has the naked attribute in their C compiler. http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf
Re: naked function attribute support for Mips
On 05/03/2013 03:29 AM, Richard Sandiford wrote:
Glad to see the push-back on this :-)
reed kotler writes:
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu :
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
Oops~ I just noticed that the mips maintainer Richard Sandiford
already had some thought about 'naked' attribute.
Refer to:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
Best regards,
jasonwucj
I think are many valid uses for the naked attribute.
Here is a simple example:
void foo() __attribute__((naked));
void foo() {
#ifdef DEBUG
C code
#else
Production code in assembly
#endif
}
You may have a very different implementation of several or many
functions when the production mode is present but for purely debugging
logic, some C code could be there.
I'm not convinced -- does anyone actually do this? If so, do they do it
for performance reasons? It would be bad if the compiler's output was
so poor that this was necessary. Plus it prevents any kind of LTO,
which seems strange for a routine that is presumably performance-critical.
E.g. it stops the compiler from generating specialised clones, or from
inlining part of the function and leaving the rest out-of-line.
This is pedantic, but: in your example, the attribute should only be
used in the "production code" case. So in practice the whole function
definition would be guarded by the #ifdef, with the attribute in the
production arm but not in the debug arm. In which case why not use
a .S file? It's surely nicer than having to write a (presumably
relatively large) asm function as a C string.
You say that naked attributes "just work". But the problem is that
corner cases keep cropping up. Your return question is a good example.
My understanding is that the compiler should never generate any code
itself for a naked function, and that naked functions must be an asm and
nothing else. In particular, naked functions must not have a return statement.
It's tempting to see:
int __attribute__((naked))
foo (void)
{
asm ("");
}
as a normal function in which the compiler just happens not generate
any prologue and epilogue code. But its reach is far wider than that.
See e.g.:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
In llvm they have a high level ir instruction called "unreachable".
I can't see why the optimizer cannot just ignore the function.
Why is this naked C assembly function any more relevant to gcc than the
external assembly file that you are proposing we use instead.
What would be good is to add another set of attributes to define the
calling convention and caller/callee saved registers. I want to do this
for llvm. That makes things even better.
where the compiler must assume that the asm returns, which is something
normal asms are not allowed to do. Another difference is that normal
asms must list the registers that they clobber (except for the usual
MIPS rule that asms can clobber $1). E.g. for:
int
foo (int x)
{
asm ("# foo");
return x;
}
the compiler is free to assume that the asm clobbers neither $2 nor $4,
and so we get:
foo:
move$2,$4
# foo
j $31
But the asm in a naked function is different, because we have to assume
that the asm can change any call-clobbered register. This matters if
you're doing IPA to figure out which functions happen to preserve which
"call-clobbered" registers (so that callers can treat them as call-saved
instead). Naked functions would be a special case that's easily forgotten.
Then there are questions like: what .cfi_* directives, if any, should
the compiler generate for a naked function? Should it generate the
.cfi_startproc and .cfi_endproc, or is that the asm's job? The answer
isn't really obvious.
That's just a list from the top of my head, I doubt it's exhaustive. :-)
Richard
Re: naked function attribute support for Mips
My general opinion is that to not allow the naked attribute is to
pontificate over a group of sophisticated gcc users that are fully
capable of understanding what the naked attribute does. They can read
the manual and accept the responsibility for using the feature.
The ramifications of the full inline asm syntax as you describe below,
are 100 times more complex to understand (and implement, test and
maintain in the compiler) than the naked attribute, and have way more
complex implications in things like LTO than functions with the naked
attribute.
People have a lot of reason to want to write assembly code in their C
program and I don't see why we feel that because we control the
compiler, that we should be preventing them from doing their job in a
way that they see fit to do it. Everyone has their own concept of best
practices and none are 100% the same.
The naked attribute completes "inline assembler". Without it, there are
things you just can't do.
While this is the gcc list, I can interject that for llvm, I implemented
mips16 stubs fully by creating high level IR for functions and then
compiling those functions with the naked attribute.
I think though that more documentation should be provided on the
attribute (as well as for the non simple forms of inline assembler...!)
Reed
On 05/03/2013 07:03 AM, Richard Sandiford wrote:
David Brown writes:
Personally, I've used "naked" when I want to write pure assembly code
and don't want extra stack frames or "return" codes. I don't want to
write stand-alone assembly files (I've written mountains of them in the
past, and hope they stay in the past). I am happier using the very nice
flexible gcc inline assembly syntax.
The full inline asm syntax, such as:
asm ("..." : "=r" (result) : "i" (100))
is specifically forbidden in naked functions, because in general GCC can
only satisfy the constraints by building its own frame:
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
the specified function does not need prologue/epilogue sequences generated by
the compiler. It is up to the programmer to provide these sequences. The
only statements that can be safely included in naked functions are
@code{asm} statements _that do not have operands_. All other statements,
including declarations of local variables, @code{if} statements, and so
forth, should be avoided.
(my emphasis). Naked functions must have a body of the form:
{
asm ("");
}
i.e. an asm with just a plain string, and no other statements or
local variables. So you don't really get any more flexibility
by using inline asms over using assembly files.
Thanks,
Richard
Re: naked function attribute support for Mips
David Brown writes:
> Personally, I've used "naked" when I want to write pure assembly code
> and don't want extra stack frames or "return" codes. I don't want to
> write stand-alone assembly files (I've written mountains of them in the
> past, and hope they stay in the past). I am happier using the very nice
> flexible gcc inline assembly syntax.
The full inline asm syntax, such as:
asm ("..." : "=r" (result) : "i" (100))
is specifically forbidden in naked functions, because in general GCC can
only satisfy the constraints by building its own frame:
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
the specified function does not need prologue/epilogue sequences generated by
the compiler. It is up to the programmer to provide these sequences. The
only statements that can be safely included in naked functions are
@code{asm} statements _that do not have operands_. All other statements,
including declarations of local variables, @code{if} statements, and so
forth, should be avoided.
(my emphasis). Naked functions must have a body of the form:
{
asm ("");
}
i.e. an asm with just a plain string, and no other statements or
local variables. So you don't really get any more flexibility
by using inline asms over using assembly files.
Thanks,
Richard
Re: naked function attribute support for Mips
On 03/05/13 10:06, Chung-Ju Wu wrote: > 2013/5/3 Chung-Ju Wu : >> >> Or do you think 'naked' is still useful for some other cases in mips porting? >> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org >> and I believe the mips maintainers are willing to have review with you. :) >> > > Oops~ I just noticed that the mips maintainer Richard Sandiford > already had some thought about 'naked' attribute. > > Refer to: > http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html > I've only used gcc on mips for a couple of small programs, and haven't needed "naked". But I've used it occasionally on other targets, and I'm with Mark Mitchell on this one. "naked" is not often useful - but when it /is/ useful, it can be very useful. In some cases you might want to use it for interrupts, if the normal interrupt framing is not suitable (on some platforms it is not quite optimal). You might want to use it in conjunction with writing a RTOS. Personally, I've used "naked" when I want to write pure assembly code and don't want extra stack frames or "return" codes. I don't want to write stand-alone assembly files (I've written mountains of them in the past, and hope they stay in the past). I am happier using the very nice flexible gcc inline assembly syntax. I am happier having all my code in C files - it fits my build process well. So some people use "naked" on some targets. Other people who don't like it, don't have to use it. But in the interests of compatibility, maintainability, code re-use (within gcc), ease of use, code re-use by users across different platforms, ease of learning, simpler documentation, and a dozen other good reasons - there should always be an aim to make attributes consistent across targets. I can well understand that some attributes will not be implemented on some targets - they are perhaps not appropriate, or there simply has not been anyone with the time to do the work. But - speaking purely as a user - it is hard to understand why a feature like "naked" would not be available on all targets. Equally, it is hard to comprehend why attributes for interrupt functions are called "interrupt" on one target, "interupt_handler" on another, and "exception_handler" on a third - and why "interrupt" will re-enable interrupts on some targets but not others. Surely it would be a good thing all round if these sorts of this were - where practically possible - consistent across targets?
Re: naked function attribute support for Mips
On Fri, May 3, 2013 at 12:29 PM, Richard Sandiford
wrote:
> Glad to see the push-back on this :-)
>
> reed kotler writes:
>> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>>> 2013/5/3 Chung-Ju Wu :
Or do you think 'naked' is still useful for some other cases in mips
porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
>>> Oops~ I just noticed that the mips maintainer Richard Sandiford
>>> already had some thought about 'naked' attribute.
>>>
>>> Refer to:
>>> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
>>>
>>>
>>> Best regards,
>>> jasonwucj
>> I think are many valid uses for the naked attribute.
>>
>> Here is a simple example:
>>
>> void foo() __attribute__((naked));
>>
>> void foo() {
>> #ifdef DEBUG
>> C code
>> #else
>> Production code in assembly
>> #endif
>> }
>>
>>
>> You may have a very different implementation of several or many
>> functions when the production mode is present but for purely debugging
>> logic, some C code could be there.
>
> I'm not convinced -- does anyone actually do this? If so, do they do it
> for performance reasons? It would be bad if the compiler's output was
> so poor that this was necessary. Plus it prevents any kind of LTO,
> which seems strange for a routine that is presumably performance-critical.
> E.g. it stops the compiler from generating specialised clones, or from
> inlining part of the function and leaving the rest out-of-line.
>
> This is pedantic, but: in your example, the attribute should only be
> used in the "production code" case. So in practice the whole function
> definition would be guarded by the #ifdef, with the attribute in the
> production arm but not in the debug arm. In which case why not use
> a .S file? It's surely nicer than having to write a (presumably
> relatively large) asm function as a C string.
>
> You say that naked attributes "just work". But the problem is that
> corner cases keep cropping up. Your return question is a good example.
> My understanding is that the compiler should never generate any code
> itself for a naked function, and that naked functions must be an asm and
> nothing else. In particular, naked functions must not have a return
> statement.
>
> It's tempting to see:
>
> int __attribute__((naked))
> foo (void)
> {
> asm ("");
> }
>
> as a normal function in which the compiler just happens not generate
> any prologue and epilogue code. But its reach is far wider than that.
> See e.g.:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
>
> where the compiler must assume that the asm returns, which is something
> normal asms are not allowed to do. Another difference is that normal
> asms must list the registers that they clobber (except for the usual
> MIPS rule that asms can clobber $1). E.g. for:
>
> int
> foo (int x)
> {
> asm ("# foo");
> return x;
> }
>
> the compiler is free to assume that the asm clobbers neither $2 nor $4,
> and so we get:
>
> foo:
> move$2,$4
> # foo
> j $31
>
> But the asm in a naked function is different, because we have to assume
> that the asm can change any call-clobbered register. This matters if
> you're doing IPA to figure out which functions happen to preserve which
> "call-clobbered" registers (so that callers can treat them as call-saved
> instead). Naked functions would be a special case that's easily forgotten.
>
> Then there are questions like: what .cfi_* directives, if any, should
> the compiler generate for a naked function? Should it generate the
> .cfi_startproc and .cfi_endproc, or is that the asm's job? The answer
> isn't really obvious.
>
> That's just a list from the top of my head, I doubt it's exhaustive. :-)
I agree with all of this. For LTO we need a way to annotate toplevel
asm()s with the symbols they require and provide, so a naked function
foo would just become
int foo (int);
asm("." : : : : );
which is much cleaner - it is then really embedding a .S file into
the TU (for whatever reason, one being the ability to make foo .local).
Richard.
Re: naked function attribute support for Mips
Glad to see the push-back on this :-)
reed kotler writes:
> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>> 2013/5/3 Chung-Ju Wu :
>>> Or do you think 'naked' is still useful for some other cases in mips
>>> porting?
>>> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
>>> and I believe the mips maintainers are willing to have review with you. :)
>>>
>> Oops~ I just noticed that the mips maintainer Richard Sandiford
>> already had some thought about 'naked' attribute.
>>
>> Refer to:
>> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
>>
>>
>> Best regards,
>> jasonwucj
> I think are many valid uses for the naked attribute.
>
> Here is a simple example:
>
> void foo() __attribute__((naked));
>
> void foo() {
> #ifdef DEBUG
> C code
> #else
> Production code in assembly
> #endif
> }
>
>
> You may have a very different implementation of several or many
> functions when the production mode is present but for purely debugging
> logic, some C code could be there.
I'm not convinced -- does anyone actually do this? If so, do they do it
for performance reasons? It would be bad if the compiler's output was
so poor that this was necessary. Plus it prevents any kind of LTO,
which seems strange for a routine that is presumably performance-critical.
E.g. it stops the compiler from generating specialised clones, or from
inlining part of the function and leaving the rest out-of-line.
This is pedantic, but: in your example, the attribute should only be
used in the "production code" case. So in practice the whole function
definition would be guarded by the #ifdef, with the attribute in the
production arm but not in the debug arm. In which case why not use
a .S file? It's surely nicer than having to write a (presumably
relatively large) asm function as a C string.
You say that naked attributes "just work". But the problem is that
corner cases keep cropping up. Your return question is a good example.
My understanding is that the compiler should never generate any code
itself for a naked function, and that naked functions must be an asm and
nothing else. In particular, naked functions must not have a return statement.
It's tempting to see:
int __attribute__((naked))
foo (void)
{
asm ("");
}
as a normal function in which the compiler just happens not generate
any prologue and epilogue code. But its reach is far wider than that.
See e.g.:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
where the compiler must assume that the asm returns, which is something
normal asms are not allowed to do. Another difference is that normal
asms must list the registers that they clobber (except for the usual
MIPS rule that asms can clobber $1). E.g. for:
int
foo (int x)
{
asm ("# foo");
return x;
}
the compiler is free to assume that the asm clobbers neither $2 nor $4,
and so we get:
foo:
move$2,$4
# foo
j $31
But the asm in a naked function is different, because we have to assume
that the asm can change any call-clobbered register. This matters if
you're doing IPA to figure out which functions happen to preserve which
"call-clobbered" registers (so that callers can treat them as call-saved
instead). Naked functions would be a special case that's easily forgotten.
Then there are questions like: what .cfi_* directives, if any, should
the compiler generate for a naked function? Should it generate the
.cfi_startproc and .cfi_endproc, or is that the asm's job? The answer
isn't really obvious.
That's just a list from the top of my head, I doubt it's exhaustive. :-)
Richard
Re: naked function attribute support for Mips
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu :
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
Oops~ I just noticed that the mips maintainer Richard Sandiford
already had some thought about 'naked' attribute.
Refer to:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
Best regards,
jasonwucj
I think are many valid uses for the naked attribute.
Here is a simple example:
void foo() __attribute__((naked));
void foo() {
#ifdef DEBUG
C code
#else
Production code in assembly
#endif
}
You may have a very different implementation of several or many
functions when the production mode is present but for purely debugging
logic, some C code could be there.
The main idea is that "naked" is there for someone that needs it.
The caller/callee saved register issue is there. In the absence of
additional function attributes, one would presume that normal abi rules
apply. But this issue is there even if you use assembly code instead of
functions with the naked attribute.
Re: naked function attribute support for Mips
2013/5/3 Chung-Ju Wu : > > Or do you think 'naked' is still useful for some other cases in mips porting? > You can implement it and submit the patch to gcc-patc...@gcc.gnu.org > and I believe the mips maintainers are willing to have review with you. :) > Oops~ I just noticed that the mips maintainer Richard Sandiford already had some thought about 'naked' attribute. Refer to: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html Best regards, jasonwucj
Re: naked function attribute support for Mips
2013/5/3 reed kotler :
> This issue of naked function attribute support for Mips has come up in the
> context of LLVM and in regards to maintaining compatibility with gcc.
>
> It's my understanding that the idea of the naked function attribute was
> rejected for gcc Mips.
>
> I'm curious as to why.
Because there is no 'naked' attribute spec for mips porting in gcc.
Refer to gcc/config/mips/mips.c:
668 static const struct attribute_spec mips_attribute_table[] = {
669 /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
670om_diagnostic } */
671 { "long_call", 0, 0, false, true, true, NULL, false },
672 { "far", 0, 0, false, true, true, NULL, false },
673 { "near",0, 0, false, true, true, NULL, false },
674 /* We would really like to treat "mips16" and "nomips16" as type
675 attributes, but GCC doesn't provide the hooks we need to support
676 the right conversion rules. As declaration attributes, they affect
677 code generation but don't carry other semantics. */
678 { "mips16", 0, 0, true, false, false, NULL, false },
679 { "nomips16",0, 0, true, false, false, NULL, false },
680 { "micromips", 0, 0, true, false, false, NULL, false },
681 { "nomicromips", 0, 0, true, false, false, NULL, false },
682 { "nocompression", 0, 0, true, false, false, NULL, false },
683 /* Allow functions to be specified as interrupt handlers */
684 { "interrupt", 0, 0, false, true, true, NULL, false },
685 { "use_shadow_register_set", 0, 0, false, true, true, NULL, false },
686 { "keep_interrupts_masked", 0, 0, false, true, true, NULL, false },
687 { "use_debug_exception_return", 0, 0, false, true, true, NULL, false },
688 { NULL, 0, 0, false, false, false, NULL, false }
689 };
Generally, 'naked' attribute is used for interrupt handler
because we don't want compiler to generate prologue/epilogue.
Since mips already provides attributes to handle interrupt handler,
it is trivial to have 'naked' one.
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
Best regards,
jasonwucj
>
> For LLVM it basically works just by nature of how LLVM works in its target
> independent part.
>
> It will not emit the function prologue or epilogue.
>
> It still emits the .frame, .mask and .fmask because that is Mips specific
> code that does not currently know about the naked function attribute, but
> that is a separate issue.
>
> There is also the issue of the return statement but this also a separate non
> Mips specific issue and I will post that separately.
>
> Tia.
>
> Reed
>
>
>
Re: naked function attribute support for Mips
On 05/02/2013 04:13 PM, Andrew Pinski wrote: On Thu, May 2, 2013 at 3:35 PM, reed kotler wrote: This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. What are the use cases of naked for mips that the interrupt attribute does not handle? Including the use_shadow_register_set, keep_interrupts_masked and use_debug_exception_return attributes which MIPS backend already handles. Thanks, Andrew Pinski For me, the reason would be so that you can control what is in the function more precisely. This would be for whatever reason you might not want default behavior from some other attribute.
Re: naked function attribute support for Mips
On Thu, May 2, 2013 at 3:35 PM, reed kotler wrote: > This issue of naked function attribute support for Mips has come up in the > context of LLVM and in regards to maintaining compatibility with gcc. > > It's my understanding that the idea of the naked function attribute was > rejected for gcc Mips. > > I'm curious as to why. > > For LLVM it basically works just by nature of how LLVM works in its target > independent part. > > It will not emit the function prologue or epilogue. > > It still emits the .frame, .mask and .fmask because that is Mips specific > code that does not currently know about the naked function attribute, but > that is a separate issue. > > There is also the issue of the return statement but this also a separate non > Mips specific issue and I will post that separately. What are the use cases of naked for mips that the interrupt attribute does not handle? Including the use_shadow_register_set, keep_interrupts_masked and use_debug_exception_return attributes which MIPS backend already handles. Thanks, Andrew Pinski
naked function attribute support for Mips
This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. Tia. Reed
