PERFORCE change 50188 for review

[Doug Rabson]

On Saturday 03 April 2004 19:22, Daniel Eischen wrote:
> On Sat, 3 Apr 2004, Doug Rabson wrote:
> > On Friday 02 April 2004 21:22, Daniel Eischen wrote:
> > > On Fri, 2 Apr 2004, Julian Elischer wrote:
> > > > The SUN API allows the destination of the %gs:0 to be changes
> > > > at runtime by the user this allowing the UTS to switch threads
> > > > "on the fly" without going back to the kernel.
> > >
> > > Yes, please, I don't see how the one extra indirection is
> > > really going to affect much.  This is where we intended to
> > > go months ago (and years ago WRT KSE in general), and
> > > everything has been designed around it.
> >
> > I was just wandering around the internet looking at the scenery and
> > I ended up here:
> > http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html.
>
> Neat.
>
> > This document describes a new options (which is not supported by
> > the compiler in current right now), -mno-tls-direct-seg-refs. This
> > looks like it will do everything we need for both i386 and amd64,
> > i.e. instead of code like:
> >
> > 	movl	%gs:x at ntpoff, %eax
> >
> > it should generate:
> >
> > 	movl	%gs:0, %eax
> > 	movl	x at ntpoff(%eax), %eax
>
> That's what I thought the SUN ABI was supposed to do, no?
> Perhaps I should go back and read the TLS spec...

The main difference, (for me anyway) is that the calling convention for 
tls_get_addr in the sun abi is a standard stack-based convention. This 
leads to bulky code sequences which are hard for the linker to 
transform when it realises that it can change a reference from e.g. 
global dynamic to local exec.

>
> > Although I'm still not quite convinced that we can't do the first
> > version with essentially zero cost for i386 at least.
>
> I think it might get messy trying to manage LDTs.  Extra
> locking will be needed when you need to borrow them from
> other threads, and you need to make sure those other threads
> aren't running and aren't scope system.  You might as well
> make a system call to continue the thread and let the
> kernel do all the work.

Probably. If we can arrange to reduce the syscall cost somewhat (e.g. 
with sysenter/sysexit instead of int $80), perhaps this still isn't too 
much of a problem. I think that most programs should do far fewer 
context switches than most other work.