[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
Hi!
> > 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
provide.
Unfortunately this might be the only real working solution?
Regards,
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