> > One can dtrace dtrace as in use the kernel framework + command to debug > > the command and library. We do this often. One cannot debug DTrace the > > kernel software, though, since you can't instrument the kernel portion of > > the instrumentation framework. This would violate the s/w laws of physics. > > I was thinking about this part. Why is this a violation of physics? A > perfect emulator can run itself like the Russian dolls, over and over > and over and over again in a nested nested nested fashion
The emulator would be a separate process, loading itself, with the nested instance having its own resources. In an arbitrary-context instrumentation framework, you've got one instance of this thing in the one kernel, with finite resources and you can't arbitrarily allocate more as you go. For example, you've got various bits and flags and state which is per-CPU, hanging off the kernel CPU data structures. You've got code which is going to do things like cross-trap the other CPUs on the system. And so on. Let's say you come into DTrace, start doing this to handle some probe, and then it turns out that part of what you need to do is call some DTrace subroutine which in turn is itself instrumented. At this point you can't just jump into yourself recursively, because you've got all this state mentioned above which is in flight. e.g. I set this bit in the CPU struct before we do this, and then this must be done before we call this other thing, etc. And you can't save and restore all of that state recursively either, for two reasons: (a) you're in arbitrary context and can't allocate resources, and (b) doing so would make the code of the framework itself incredibly over-complex and time and space inefficient. Debugging the debugger, emulating the emulator, and compiling the compiler are only possible when each instance of the thing has its own separate resources (usually an address space) and doesn't need arbitrarily recursive state save/state restore. With an in-kernel framework or anything like it, you're trying to make a part of a much larger program (the kernel) an arbitrarily recursive debugger of itself, and that is what can't work in that you are limited in resources and will end up violating your own design criteria (time and space efficient, arbitrary context, etc.) -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
