[En-Nut-Discussion] Not fixed!!!: Re: confirmed!!! Re: NutOS 4.4.0 on ARM7: possibly bug in NutEnterCritical / NutExitCritical

[Matthias Ringwald]

Hi Nathan

and others. Ok. I'm convinced that the problem you're discussing might  
occur.

>>
>>
>> - Even if they call other functions, those return and the  
>> ExitCritical
>> is in the same context as the entry.
>
> Not if you pass arguments.  The compiler may use the stack to save  
> local
> variables that are in registers  or may pass some variables on the  
> stack.
> Say you did:
>   NutEnterCritical();
>   A = value_that_isr_can_change;
>   NutExitCritical();
>   printf("%i", A);
> Since A will end up on the stack anyway (all the variable length  
> argument
> list arguments are always put on
> the stack) the compiler may put it there initially within the critical
> section which will break stuff since A will
> end up being used as the value NutExitCritical uses to restore the
> interrupts.  printf will then print the interrupt
> state that was supposed to be restored if printf works with  
> interrupts off.

In this case, A is withing the stack frame (I think it's called like  
this).
Push would use unallocated space. Although, I just got a bigger  
question.
is there both a stack frame pointer AND a stack pointer?
If no, then either accessing local variables after pushing a value on  
the stack
would access the wrong memory, or, the compiler has to keep track, how  
many values it already pushed on the stack. possible but tough. not  
sure if anybody does understand this - it's not important really, if  
NutEnterCritical is to change.

>>
>>
>>>> had wondered about this on AVR, which is what we are using. A
>>> wonderful way to ruin everything would be to use alloca( ) within a
>>> critical section.
>> But. First, calling an indeterministic function (in terms of running
>> time) from within an IRQ is a no-no, which must not be done.
>> Second, people writing IRQ-Handler should know why they did call
>> NutEnterCritical in the first place.
>
> IRQ handlers aren't supposed to be calling enter/exit critical since  
> they
> are already in the critical state.
Sorry. True.
>
> alloca( ) is not an indeterministic function.  All it does is tell the
> compiler
> that you want to allocate more space on the stack and give you a  
> pointer
> to that.

Again, I'm sorry, didn't really think here.

>>
>>
>> The point about NutJumpCritical is there, but I think in most cases
>> the code can be reformulated to avoid it.
>
> I agree w/ this.
:) good. that's a start. :)

matthias