[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-mdb-discuss
Subject:    Re: [mdb-discuss] using kernel CTF with raw disk
From:       "max () bruningsystems ! com" <max () bruningsystems ! com>
Date:       2007-09-25 6:05:59
Message-ID: 46F8A547.9020309 () bruningsystems ! com
[Download RAW message or body]

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
>
>   

_______________________________________________
mdb-discuss mailing list
mdb-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]