> Hi > Hi Gavin, > If it's just context switching you want to observe > you could use DTrace on a live non-simulated system. > But I > uess that's not what you're aiming at. > No, that is not what I'm aiming for. Once the simulator is halted/triggered I can only do memory reads/writes.
> 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. I can add a so called "magic instruction" to these entry points, which will trigger the simulator to stop when they are executed. However, I would like to avoid re-compiling the kernel =) > Remember that there are > few %g7 registers - from the regular, interrupt, > alternate and mmu > lobal register sets. %g7 is used as CURTHREAD in the > kernel with the > regular globals only. > I'm looking at the global register (I think) once in privileged mode. Is that wrong? > 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. Yes, you are right that many events can trigger a mode switch. However, my understanding is that _only_ context switch code will do writes to the curthread i.e. global register %g7 (if a new thread is to execute). Hmm...That is under the assumption that I look in the right g7 (if there are several) I might be looking at the wrong %g7. 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 > ow you trigger on "transitions into kernel mode". > I will look through this again. Thanks for the comments on this! > 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. > mdb might solve the offset question I had. Thanks again! /Mladen This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
