On Mon, Jan 21, 2002 at 01:59:10PM -0500, Daniel Jacobowitz wrote:
> 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" <firstname.lastname@example.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.
What is wrong about using a thread register as long as it contains
the right value when it is accessed as a thread pointer? If
applications don't have access to the thread pointer, I don't see the
problem using the thread register.