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

Ole Reinhardt ole.reinhardt at embedded-it.de
Thu Feb 21 17:32:15 CET 2008


> > 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.
> I 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.
> I think that it's really hard to get them right and allow critical
> sections be reentrant without making the users of critical section
> handle the status register data themselves  -- make NutEnterCritical
> either return a value or take an OUT parameter and NutExitCritical
> take an IN parameter.  Big change...

Yes. As I understand the current implementation of NutEnterCritical /
NutExitCritical the original value of the CPSR is saved on the stack to
allow a later restore. This _must_ fail if the stack will be modified in
the meanwhile.

Other operatin systems implement it the way you propose (e.g. Linux:
spinlock_irq_save()) and save the flags in a variable you need to

Unfortunately this might be the only real working solution?


Ole Reinhardt

|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |

More information about the En-Nut-Discussion mailing list