> Date: Mon, 21 Jan 2002 10:52:53 -0800 > From: "H . J . Lu" <hjl@lucon.org> > Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, > "Kevin D. Kissell" <kevink@mips.com>, > Machida Hiroyuki <machida@sm.sony.co.jp>, > GNU C Library <libc-alpha@sources.redhat.com>, linux-mips@oss.sgi.com > 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. This won't work, will it? We need a register that application code is not allowed to change ever, not one that is saved and restored. Even if the user knows that no glibc routines are called between the save and the restore, a signal could happen. -- - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
