> Question #1 > I was looking at the code of resume() at swtch.s. The %g7 resister > seems to hold a pointer to the thread structure. Is that pointer to > the user-level one or the kernel-level one?
In the kernel, the %g7 register contains the address of the kthread_t structure that is the thread running on the current CPU. This is the value of CPU->cpu_thread. > I have this question because of my following confussion; if %g7 holds > a pointer to the kernel thread then somehow it needs to be not > available to user-mode since this will violate process/kernel > boundaries. On the other hand if it points to user-level structure, > then it is not reasonable since that structure could be modified by > user-mode. Clearly I am missing something here. I know that in SPARC > there is this alternate global set. Does the kernel use that alternate > global? Or does the kernel clear the %g7 register before getting to > user mode? If this is the case, could someone point me to the place > where this happen? The %g7 register is setup by the trap code. On sun4u, user_trap() determines the CPU->cpu_thread, stashes it in %l6 and calls utl0(). The code in utl0() moves %l6 to THREAD_REG which is defined as %g7. In the syscall case, the utl0() code then invokes the sycall_trap handler. utl0, unless I'm mistaken, vectors to the TL0 trap table. Outbound, the proces is reversed in user_rtt(). Parenthetically, the SysV ABI for SPARC lists the %g registers as reserved for system software. code which is ABI compliant shouldn't be setting the %g7 register. However, the kernel obviously doesn't trust the value of %g7 from userland and, as mentioned above, generates the correct value when a trap is taken. -j _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
