cli/sti in i386/setjmp.S

[Corinna Vinschen]

On Jan 27 18:34, Joel Sherrill wrote:
> Hi
> 
> 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):
> 
>        __CLI
> 	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
>        __STI
> 	ret
> 
> 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:
> 
> https://github.com/lattera/freebsd/blob/master/lib/libc/i386/gen/setjmp.S
> 
> 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?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160128/5913824d/attachment.sig>