Thanks, adam. It is rather helpful. zhijun Adam Leventhal wrote: > Hi Zhijun, > > ::whatis works by examining the kmem_cache or segment that contains the given > address. For static data you'll see something like this: > > >> fffffffffbc25dc0::whatis >> > fffffffffbc25dc0 is p0+0 in unix's data segment > > For dynamically allocated objects you'll see the kmem_cache from which it was > allocated: > > >> ffffffffae22e3d0::whatis >> > ffffffffae22e3d0 is ffffffffae22e3d0+0, allocated from process_cache > >> 0xffffffff8d880c40::whatis >> > ffffffff8d880c40 is ffffffff8d880c40+0, bufctl ffffffff8d999e88 allocated > from kmem_alloc_24 > > The kernel doesn't maintain type information for every object, but it does for > some named kmem_caches. Take a look at ::kmem_cache for a sampling. The kernel > _does_ however, have definitions of all types and can apply Bryan Cantrill's > clever algorithm for walking types to try to infer the type of every object. > This is done with the ::typegraph, and ::whattype dcmds. > > http://arxiv.org/abs/cs/0309037 > > Adam > > On Wed, Oct 18, 2006 at 10:47:42AM +0800, Fu Zhi-jun wrote: > >> Hi, folks, >> I have a question about the internals of dcmd "whatis". >> The dcmds "whatis" gives the type information of an address. >> I am curious how this dcmd get that information. Does Solaris kernel >> memory system >> maintain that information for each allocation? >> >From the code which implements "whatis", it walks thread-stack, page, >> kmem_cache ... in turn, and try to locate the address within each part. >> So it seems solaris doesn't >> maintain type information for dynamic allocated objects. Is it correct? >> >> Thanks, >> Zhijun >> _______________________________________________ >> mdb-discuss mailing list >> mdb-discuss at opensolaris.org >> > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20061023/15c49b8f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Zhijun.Fu.vcf Type: text/x-vcard Size: 45 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20061023/15c49b8f/attachment.vcf>
