This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cli/sti in i386/setjmp.S


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

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]