Michael Shapiro wrote: >> Hi Eric, >> >> Eric Schrock wrote: >> >>> The power of debugging, in general, is lost on most developers. Thanks >>> to the work we've done in OpenSolaris (DTrace, MDB, CTF, ptools, etc), >>> the average OpenSolaris developer is vastly more engaged than your >>> typical developer. But as we've time and time again, you need to build >>> the tools first before developers can get excited about it. Just the >>> other day I found myself wanting ::loadctf, because I had used ::context >>> to examine a userland process from a crash dump, but I had no CTF data >>> available to print structures. It was sitting on disk, but there was no >>> way to tell MDB to load it. There are definitely some powerful things >>> you are doing that will be useful to developers. The mdb fanatics >>> among us are definitely hoping you'll continue your work. >>> >>> >> I've thought about this some more. I assume you have a full memory dump >> when >> you switch context from the kernel to examine a userland process. I >> think the ability >> to load ctf information for the process would be extremely useful. >> Probably more useful >> than using CTF with the raw disk. I'll look into this shortly. >> >> max >> > > Unfortunately solving this in kproc is tough for a couple of reasons: > > (1) We don't have all pages in kernel: only those that were in physical > at the time of the panic. But you do get a lot of them -- see > usr/src/cmd/mdb/common/mdb/mdb_kproc.c for how this works. > Oops. I had forgotten that, of course, some pages could be paged out. If the dump was on a dedicated dump device, and you had all of the swap space available, you could easily enough find the missing pages on swap... I'll take another look at mdb_kproc.c > (2) Right now CTF data isn't in-memory in userland processes: it's loaded > from the object file by the debugger. Therefore there is no way to > easily get to it from a kernel dump. > > Solving #2 is just a mess. A better solution is to let someone reconstruct > things in the debugger. Basically what you want is, at the generic target > layer, the ability to associate an external CTF file with a module exported > by the target (i.e. ::loadctf or somesuch). > > Once you ::context into the kproc target, you then say: > > ::loadctf a.out /usr/bin/pgrep > > to associate the a.out mapping with any CTF data we can find in /usr/bin/pgrep > for example. This is relatively easy code to write, and can work with any > target since all you're doing is interposing at the common target layer. > I'll take a look. thanks, max
> -Mike > >
