cli/sti in i386/setjmp.S
Thu Jan 28 10:37:00 GMT 2016
On Jan 27 18:34, Joel Sherrill wrote:
> Gedare and I are working on a paravirtualized port of RTEMS to
> a hypervisor. The code will be running in user space which
> changes the rules a bit over our normal bare metal environment.
> Gedare debugged a test failure which turned out to be that
> i386/setjmp.S uses sti/cli to protect this sequence of code
> on bare metal (edi points to the jmpbuf):
> movl 28(edi),esp
> pushl 32(edi)
> movl 0(edi),eax
> movl 4(edi),ebx
> movl 8(edi),ecx
> movl 12(edi),edx
> movl 16(edi),esi
> movl 20(edi),edi
> The cli/sti were turned into macros in 2000 and were apparently
> there when the source code history started.
> The only way I see the cli/sti needed is to protect against
> the where where jmpbuf is on the stack and could be clobbered
> by ISRs or signals being processed on the same stack while
> the information is used. This could occur on a real UNIX
> system as well as an embedded target.
> The FreeBSD setjmp.S is here as a point of comparison:
> I checked the m68k implementation as a point of reference
> and it loads the sp near the end but might have a one
> instruction window for the same situation.
> I question the inclusion of interrupt disable instructions.
> If the code has a critical section issue, then it likely exists
> in every environment, not just embedded ones. And other
> setjmp implementations don't disable interrupts.
> I would prefer to have a single version of setjmp/longjmp
> that works in user and supervisor mode.
> Any ideas, thoughts on why the cli/sti are here?
This stuff predates me, so I have no idea, but wouldn't redefining
__CLI/__STI as empty macros do the trick while keeping them in for
the dubious reasons they have been added in the first place?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Newlib