> > 0x3000a1733a8::print queue_t q_first |::list mblk_t > b_next|::print > mblk_t b_rptr|::dump > > But ::dump will only give the data content of the > first mblk, it cannot give the content of all mblks.
Hmm... you seem to have found a bug. You can work around it by instead piping to "::map ::dump". > Instead,I wrote a simple dcmd called mblk_dump, and > it works: Nice workaround :) BTW, though you shouldn't need to go off and write your own dcmds for this, the ::dump functionality is available as mdb_dumpptr() and mdb_dump64() in the dcmd API in case you do (it might make things a little easier). > Simple as it is, I am wondering why dump only work with the first > element instead of accepting a list of addresses. It is tedious and > error-prone to display the content of each mblk when there is hundreds > of them, it is much desirable to print the content of all mblks (in a > queue) with a single dcmd in this case. > So isn't it better to have a dcmd that can accept a list of addresses > and "dump" their contents? > Is there any reason for ::dump 's current behaviour? At first blush, I'd say it's a bug. Looking at the source, we return DCMD_ABORT in the DCMD_LOOP case: http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/mdb/common/mdb/mdb_cmds.c#2153 This means that any attempt to ::dump the results of a ::walk will terminate after the first iteration. The reason for doing this, as I recall, is because an address,count invokation is treated a little like a walker by MDB, but needs to be interpreted directly by ::dump. Returning DCMD_OK means you'd get a deluge of unrequested ::dump output. This should work, so there's a bug. I think fixing it may require changes to more than ::dump, though. Dave This message posted from opensolaris.org
