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" <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. 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. H.J.
