On Mon, Jan 21, 2002 at 11:05:33AM -0800, H . J . Lu wrote: > 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. When is the thread pointer accessed? My understanding was that it would be needed for the lifetime of the application, in functions called from the application. In that case its value can not be trusted. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
