Jim Glent wrote:
Hi,
I am facing difficulties with some kernel code on SPARC v9. Specifically, most 
of the times it seems
> that the altername %g5 register contains a pointer to the current kthread_t 
struct in kernel memory.
Following some exceptions, for example 0x8C (spill 3 normal), %g5 is wiped out. Where can I find this
> pointer then?

I can't remember any special use for %g5 in the kernel.  As you say below. %g7 
is
'curthread' and reflects the thread currentlu executing on cpu (which may not
be the dispatched thread cpu.cpu_disp_thread - if a low level interrupt has
hit that then %g7 will show the interrupt thread;  if a high level interrupt
strikes that does not modify curthread at all (and such handlers should not
reference curthread).

Remember that there are multiple sets of globals - regular, interrupt, alternate
and mmu globals.  Each trap type will select an appropriate set of globals,
and then the handler may even choose to shuffle between sets.  So if %g7
holds a thread pointer and an interrupt arrives we switch to IG and
we can change %g7 there without affecting the %g7 that holds curthread.

I know that a more proper way to do this might be, beginning from the "cpu" (as 
shown by mdb) array and
> doing cpu[<cpu_id>]->cpu_thread, but this does not seem to produce correct 
results, as it always points
> to a thread of the "sched" process.

I think all kernel threads that do not support a userland thread (ie pure kernel
thread) are associated with the articifical "sched" process.


I also know that the normal %g7 register is supposed to hold a pointer to the current kthread_t. After
> all, in the whole kernel code "curthread" is #defined as "threadp()" and 
"threadp()" returns the
> contents of %g7. However, this %g7 seems not to reside in kernel memory, and 
I really should not
access user memory in solving this problem.

In summary, I need to know where can I find a corrent pointer to the kthread_t 
that is actually executing.

Is this in kernel code (if so whereabouts)?  post-mortem debug?  Dtrace?

Cheers

Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to