Hi
On 04/11/06 10:13, Mladen Nikitovic wrote:
Hi,
I'm doing an experiment using a full-system simulator running a simulated sparc machine with solaris 10. I would like to detect context switches and print out processs-specific information such as the pid, the command name, etc.
If it's just context switching you want to observe you could use DTrace on a
live non-simulated system. But I
guess that's not what you're aiming at.
My current approach is to detect both transitions into kernel mode and writes to register %g7. This seems to indicate a context switch. Once there, the register seems to point to the running thread. I have looked the code in the source browser here and noticed some interesting entries such as p_pid in the proc structure (that can be reached from the _kthread structure) and u_comm entry in the user structure (correct? maybe this entry does not point to the command?).
Updates to %g7 used as CURTHREAD occur in resume() (see swtch.s). It is there
that
we stash the state of the current thread (if necessary) and transition to
running another specified thread. You may be better of looking at entry
and return from resume and resume_from_idle. Remember that there are
a few %g7 registers - from the regular, interrupt, alternate and mmu
global register sets. %g7 is used as CURTHREAD in the kernel with the
regular globals only.
Transitions into kernel mode do not necessarily involve a formal context switch.
Fast trap handlers, for instance, such as DMMU miss will run at traplevel > 0
without performing a context switch. It is only when we decide we need to
stay a while in the kernel - go to C code - that we perform a context switch
by jumping to sys_trap which will save state as necessary, change the
primary context register to the kernel context etc. So be careful
how you trigger on "transitions into kernel mode".
The problem I'm facing is to actually access these entries without being able
to use symbols such as curthread and so on. I can only read (and write)
directly to memory and cannot access symbols, so my question is whether there
are defined offset values that I can use to access these entries? Or is there
any other way to do this? I'm thankful for any suggestions you might have.
If you go the offset route then (for a particular kernel rev etc) use mdb -k
along with ::print and ::offsetof to extract offset info. eg,
'::print -at cpu_t' will show you the members of cpu_t with type
and offset info.
Hope that helps
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
