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

[<Paul dot Koning at dell dot com>]

> 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