Potential bug on Cortex-M due to used registers/interrupts.

Potential bug on Cortex-M due to used registers/interrupts.

[Vitalijus Jefišovas]

On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
other registers onto the psp stack, and then jumps to interrupt routine,
when it finishes, NVIC restores these registers, and jumps back to user’s
function.
What is happening under the hood, NVIC only stacks 4 registers, r0, r1, r2,
r3. The other ones r4-r12 is developer’s responsibility.
I was looking at assembly code generated by GCC and there are plenty of
instructions using r4-r12 registers.



How does GCC handle scenario when execution is switched to unknown
procedure, which changes all of these registers?

Regards.

Re: Potential bug on Cortex-M due to used registers/interrupts.

[Paul.Koning]

> On Nov 16, 2017, at 11:54 AM, Vitalijus Jefišovas <jefisovas@gmail.com> wrote:
> 
> On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
> other registers onto the psp stack, and then jumps to interrupt routine,
> when it finishes, NVIC restores these registers, and jumps back to user’s
> function.
> What is happening under the hood, NVIC only stacks 4 registers, r0, r1, r2,
> r3. The other ones r4-r12 is developer’s responsibility.
> I was looking at assembly code generated by GCC and there are plenty of
> instructions using r4-r12 registers.
> 
> How does GCC handle scenario when execution is switched to unknown
> procedure, which changes all of these registers?

Seems obvious to me.  If basic interrupt handling saves only a few registers, the assumption clearly is that many small interrupt handlers will only use those registers, so this makes things faster.

But it also means that any interrupt handler that uses registers other than those that were saved before is itself responsible for saving and restoring them.  The only way the concept of an interrupt makes sense is if it is invisible to the interrupted code.  That means that any application-level state is preserved across an interrupt.  How and where that is done doesn't matter, that's an internal detail of a particular interrupt path.

The only exception I can think of is when you have one or two registers that are explicitly reserved only for use in exception handlers -- such as the K0/K1 registers in MIPS.  But this is quite rare, I can't remember seeing it anywhere else.

So the answer is: GCC doesn't handle that case because it's not allowed to happen.

	paul

Re: Potential bug on Cortex-M due to used registers/interrupts.

[Kai Ruottu]

Vitalijus Jefišovas kirjoitti 16.11.2017 klo 18:54:
> On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
> other registers onto the psp stack, and then jumps to interrupt routine,
> when it finishes, NVIC restores these registers, and jumps back to user’s
> function.
> What is happening under the hood, NVIC only stacks 4 registers, r0, r1, r2,
> r3. The other ones r4-r12 is developer’s responsibility.
> I was looking at assembly code generated by GCC and there are plenty of
> instructions using r4-r12 registers.
>
>
>
> How does GCC handle scenario when execution is switched to unknown
> procedure, which changes all of these registers?

Cortex-M is an ARM-architecture processor or how?  So one uses things 
related to ARM
or how?

With ARM one uses function attributes available for ARM when the 
question is about a
special function like an ISR ("Interrupt Service Routine").  From the 
GCC 7.2.0 manual :

----------------- clip ------------
6.31.4 ARM Function Attributes

These function attributes are supported for ARM targets:

interrupt
   Use this attribute to indicate that the specified function is an 
interrupt handler.
   The compiler generates function entry and exit sequences suitable for 
use in an
   interrupt handler when this attribute is present.
   You can specify the kind of interrupt to be handled by adding an optional
   parameter to the interrupt attribute like this:
      void f () __attribute__ ((interrupt ("IRQ")));
   Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and 
UNDEF.

   On ARMv7-M the interrupt type is ignored, and the attribute means the 
function
   may be called with a word-aligned stack pointer.

isr
   Use this attribute on ARM to write Interrupt Service Routines. This 
is an alias
   to the interrupt attribute above.
----------------- clip ------------

How this attribute works with the NVIC I don't know but using the aimed 
attribute
and seeing the result is one way to see what will happen...

Re: Potential bug on Cortex-M due to used registers/interrupts.

[David Brown]

On 16/11/17 17:54, Vitalijus Jefišovas wrote:
> On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
> other registers onto the psp stack, and then jumps to interrupt routine,
> when it finishes, NVIC restores these registers, and jumps back to user’s
> function.
> What is happening under the hood, NVIC only stacks 4 registers, r0, r1, r2,
> r3. The other ones r4-r12 is developer’s responsibility.
> I was looking at assembly code generated by GCC and there are plenty of
> instructions using r4-r12 registers.
> 
> 
> 
> How does GCC handle scenario when execution is switched to unknown
> procedure, which changes all of these registers?
> 

These other registers - r4 to r12 - are "callee saved".  That means that
a C function that uses them will first save the old values (push them
onto the stack), and will restore them at function exit.  So the C
compiler can generate a normal function with normal ARM eabi linkage and
calling conventions, and use it directly for an interrupt function (this
is one of the nice features of the Cortex-M architecture).  "caller
saved" registers, r0-r3 - the ones that the C function can use freely -
are saved by the hardware.  The others are saved by compiler-generated
instructions as needed.

Re: Potential bug on Cortex-M due to used registers/interrupts.

[Wilco Dijkstra]

Hi,

> These other registers - r4 to r12 - are "callee saved".

To be precise, R4-R11 are callee-saved, R0-R3, R12, LR are caller-saves
and LR and PSR are clobbered by calls. LR is slightly odd in that it is
a callee-save in the prolog, but not in the epilog (since LR is assumed
clobbered after a call, it doesn't need to be restored, so you can use
pop {regs,PC} to return).

Cortex-M hardware will automatically save/restore R0-R3, R12, LR, PC, PSR
on interrupts. That perfectly matches the caller-saves and clobbered
registers, so there is no potential bug.

Wilco