cli/sti in i386/setjmp.S

[Joel Sherrill]

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?

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985