__attribute__((naked)) with C code

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

__attribute__((naked)) with C code

Joseph Sible
I notice that GCC's documentation [1] says "Only basic asm statements
can safely be included in naked functions (see Basic Asm). While using
extended asm or a mixture of basic asm and C code may appear to work,
they cannot be depended upon to work reliably and are not supported."
However, a lot of our example code contains naked functions with C
code, such as [2], [3], and [4], as well as indirectly via ISR_NAKED,
such as [5] and [6]. Is there a reason that GCC's documentation
doesn't apply to us here, or is it only by sheer luck that none of
these have resulted in problems in practice?

[1] https://gcc.gnu.org/onlinedocs/gcc/AVR-Function-Attributes.html
[2] http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections
[3] http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_softreset
[4] http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html#details
[5] http://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga15aea81a8985a4c3cc9c8b00a06f5d31
[6] http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#attr_interrupt

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((naked)) with C code

Bill Westfield
They can't be "depended upon" to work, but those examples have had their code generated carefully examined to ensure that they do work.

Several of the examples are also in the .init3 section, which executes essentially before C is set up, so they're somewhat free to do what they want.  Some other examples use statements that are 'well known' to not interfere with system state (calls to other void functions generate simple "call" statements, reti() is an intrinsic for the reti instruction, etc.) 
PORTB |= _BV(0); // results in SBI which does not affect SREG

in example 6 Is particularly dangerous; while that statement results in a single SBI instruction that doesn't affect registers or flags, a similar statement with a different port might not:

PORTL |= _BV(0);  // results in several instructions, needs a register.

On Fri, Jun 2, 2017 at 6:27 PM, Joseph Sible <[hidden email]> wrote:
I notice that GCC's documentation [1] says "Only basic asm statements
can safely be included in naked functions (see Basic Asm). While using
extended asm or a mixture of basic asm and C code may appear to work,
they cannot be depended upon to work reliably and are not supported."
However, a lot of our example code contains naked functions with C
code, such as [2], [3], and [4], as well as indirectly via ISR_NAKED,
such as [5] and [6]. Is there a reason that GCC's documentation
doesn't apply to us here, or is it only by sheer luck that none of
these have resulted in problems in practice?

[1] https://gcc.gnu.org/onlinedocs/gcc/AVR-Function-Attributes.html
[2] http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections
[3] http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_softreset
[4] http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html#details
[5] http://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga15aea81a8985a4c3cc9c8b00a06f5d31
[6] http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#attr_interrupt

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list