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

[Matthias Ringwald]

Hi

sorry for joining in late. I have a question on this:

On 21.02.2008, at 15:56, Nathan Moore wrote:

>> NutEnterCritical reads the CPSR and pushes it onto the stack.
>> NutExitCritical pops one word from the stack and writes this value  
>> back
>> to the CPSR.
>
>> Since NutEnterCritical and NutExitCritical are #defines and not  
>> functions
>> there is no guarantee that the code between Enter and Exit does not
>> change the stackpointer. So in this case both the CPSR and the  
>> intended
>> stack information will be wrong.

Maybe my assumptions are wrong:
- NutEnterCritical/NutExitCritical guard short sections of code which  
run with IRQs disabled
- These are normally just a few lines to block IRQs minimally
- They normally don't call other functions.
- Even if they call other functions, those return and the ExitCritical  
is in the same context as the entry.
- The stack pointer points to free space after the local (stack based)  
variables. You can push/pop stuff there
as long as the pointer is correct before you exit.
- If you call another function, the parameters are pushed on the  
stack, the call executed and the functions returns. an eventually  
stored ISR is still safe on the stack.

Ok. So in which case is the ISR changed.

I can see the point in this:

>> 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.

The point about NutJumpCritical is there, but I think in most cases  
the code can be reformulated to avoid it.

cheers
  matthias