• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 7331 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why nested interrupt corrupt Link Register?

Harri Wijaya
Note: This was originally posted on 13th June 2012 at http://forums.arm.com

hi,
Sorry for this basic question.

I find hard to understand why the Link Register can be corrupted in this below scenario:
1. IRQ interrupt occur.
2. IRQ ISR call a function foo(). (assume inside ISR, the IRQ interrupt is reenabled)
3. foo() is interrupted by another IRQ interrupt.

From what I understand:

*During (1):

STACK content:
some general purpose registers
LR_irq_1 (let call like that to indicate that the content is point to address of interrupted function by scenario-1)

LR_irq = address-1 (see LR_irq_1)

*During (2):

STACK content:
some general purpose registers
LR_irq_2
some general purpose registers
LR_irq_1

LR_irq = address-2 (address of a line within ISR)

*During (3):

STACK content:
some general purpose registers
LR_irq_3
some general purpose registers
LR_irq_2
some general purpose registers
LR_irq_1

LR_irq = address-3 (address of a line within foo() where second IRQ interrupt occur)


Assuming that we have enough IRQ stack size, then from above context, seem no reason for LR to be corrupted.

Any body could help me explain what causing LR to be corrupted?

Thanks!
Parents
  • Note: This was originally posted on 14th June 2012 at http://forums.arm.com

    OK, finally I found out what happen after view some dis-assembly of function calling.
    The root cause to the possibility of corruption on LR register is because compiler optimization, i.e. compiler will only generate function prologue for saving registers to stack only on registers that *are used in caller* AND *used in callee*. So when function callee doesn't have any function call inside (will doesn't have BL -branch with update LR- instruction), the function prologue WILL NOT push the LR to the stack!
    So now I understand why if another IRQ interrupt interrupting a function that is called by IRQ interrupt, it will destroy LR_irq of the function as it's not pushed to stack.
    Example, if this foo() function is called by ISR:

    void foo(void)
    {
        bState = 0;
        MACRO_THING(bState);
        bState = bar(bState); // i call another function here
        bState++;
    }
    char bar(char state)
    {
        state &= GLOBAL_SOMETHING;
        return (state >> 4);
    }
    Because foo() contain another function call, its prologue will save LR to stack. So when another IRQ interrupt interrupting foo(), no issue.
    BUT, because bar() doesn't call any other function, the prologue will not save LR to stack; so bar() is vulnerable to another IRQ interrupt!



    Clear crystal to me :)

    Thanks.
Reply
  • Note: This was originally posted on 14th June 2012 at http://forums.arm.com

    OK, finally I found out what happen after view some dis-assembly of function calling.
    The root cause to the possibility of corruption on LR register is because compiler optimization, i.e. compiler will only generate function prologue for saving registers to stack only on registers that *are used in caller* AND *used in callee*. So when function callee doesn't have any function call inside (will doesn't have BL -branch with update LR- instruction), the function prologue WILL NOT push the LR to the stack!
    So now I understand why if another IRQ interrupt interrupting a function that is called by IRQ interrupt, it will destroy LR_irq of the function as it's not pushed to stack.
    Example, if this foo() function is called by ISR:

    void foo(void)
    {
        bState = 0;
        MACRO_THING(bState);
        bState = bar(bState); // i call another function here
        bState++;
    }
    char bar(char state)
    {
        state &= GLOBAL_SOMETHING;
        return (state >> 4);
    }
    Because foo() contain another function call, its prologue will save LR to stack. So when another IRQ interrupt interrupting foo(), no issue.
    BUT, because bar() doesn't call any other function, the prologue will not save LR to stack; so bar() is vulnerable to another IRQ interrupt!



    Clear crystal to me :)

    Thanks.
Children
No data