From: "Daniel Jacobowitz" <dan@debian.org>
> On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote:
> > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote:
> > > "H . J . Lu" <hjl@lucon.org> writes:
> > >
> > > > Ulrich, should applciations have access to thread register directly?
> > >
> > > It doesn't matter. The value isn't changed in the lifetime of a
> > > thread. So the overhead of a syscall wouldn't be too much. And
> > > protection against programs overwriting the register isn't necessary.
> > > It's the program's fault if that happens.
> >
> > Thq question is if we should reserve $23 outside of glibc. $23 is
> > a saved register in the MIPS ABI. It doesn't change across function
> > calls. If applications outside of glibc don't need to access the
> > thread register directly, that means $23 can be used as a saved
> > register. We don't have to change anything when compiling applications.
> > We only need to compile glibc with $23 reserved as the thread register.
>
> That's not right. If it is call-saved in the application, that means
> the application can use it. Main may have to restore it before it
> returns to __libc_start_main, but that doesn't do you any good.
>
> It doesn't change across function calls, but it does change inside
> function calls.
You are quite correct, and you have stated the problem very
succinctly. We cannot, as I had hoped, simply superimpose
a thread pointer on a static register and keep it otherwise
invisible to the code generator. So it's not the "easy way
out".
That does not necessarily mean that it's the wrong
solution. As Maciej has pointed out, from the standpoint
of performance, making the kernel do gymnastics to
preserve or set up a "k" register on each trap may
well be worse for overall performance than having
one fewer "s" register. Stealing the "s" register
would involve a change to the ABI and the compiler,
but would make it invisible to the kernel. Using
(or abusing) a "k" register would techncially also
require a change to the ABI (though one that would
be more perfectly backward compatible), a smaller
perturbation of the compiler (thread pointer stuff
gets added, but the s-register compliment is unchanged),
and a kernel hack that may or may not conflict with
other people's work (e.g. Sony). I've been kicking this
around with my colleagues at MIPS, and as I say,
I hope to be back with a semi-official recommendation
shortly. Meanwhile, I'm very interested in other's views
of the pros, cons, and alternatives.
Regards,
Kevin K.
