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

[Matthias Ringwald]

Ok. I and just formulated my not-knowledge in private mail, too.

On 22.02.2008, at 18:26, Ole Reinhardt wrote:

> ..
> In general you are right, but there is one point you missed:
>
> NutEnterCritical is a macro. It's just a short pice of assembler code
> that leaves the stack modified. NutExitCritical is a macro too and
> expects the stack in the same manner as NutEnterCritical leaved it.
>
> The compiler does not know about modifiing the stack. The compiler may
> use the stack for whatever. This also includes the possibility to
> temporarily store some values on the stack if registers are needed for
> any other purpose. You don't know if and when this option is used. If
> this happens in a critical section, the stack is corrupted and  
> returning
> from the critical section destroys the stack.

Does GCC produce such code? Couldn't it reserve this extra space in the
beginning of the function similar to local variables.

I do see the potential problem. But is there an example that this  
happens, or is this hypothetical?

>
>
> This might be the reason why optimized code does not trigger this
> problem that often as most values are held in registers and not on the
> stack.
Using register is quite natural for a compiler. I would not assume  
that the compiler does not
use them as good as possible if you don't give some optimization  
settings. :)

matthias