Garrett D'Amore: [developer] webrev: pfile postmortem support

UPDATE:
Just noticed in repository that this work has been integrated:

changeset:   13875:f128a109e6d2
user:        Garrett D'Amore
date:        Fri Nov 02 09:48:42 2012 -0700
summary:     3294 pfiles postmortem support

Sorry that it goes through my blog, but I can't work through listbox weird URLs.
This is bit dated, as the thread started back in October. There is an interesting thread going just after this mail with reviews, but if you want to read it, go to listbox archive and search for "webrev: pfile postmortem support".
Below a quote from Garrett's mail that explains everything cleanly:

From: Garrett D'Amore 
Subject: [developer] webrev: pfile postmortem support
To: "developer@lists.illumos.org" 

http://cr.illumos.org/~gdamore/pfiles/

This adds the ability to use pfiles to get file information on a core dump.=
  To support this, I've had to create a new elf note, NT_FDINFO, and a stru=
cture for it (prfdinfo_t), which contains a bunch of information about open=
 file descriptors.  I've also added support for dumping this note into elfd=
ump.

This is the result of work I began at the illumos hackathon earlier in the =
month, and I've finally had time to get it to the point where I think its r=
eady for people to try, and also review it.  I think its fairly fully baked=
.  It works with both core files generate via gcore, and kernel generated c=
ore files.  (The two core dump generators are totally different code, addin=
g substantially to the effort.  Sadly I've had to teach elfexec far more ab=
out the kernel's user and file structures to support this than I'd like =85=
 the lack of good interfaces to those structures is an area of weakness in =
our current kernel subsystems.)

One thing that this doesn't do is go into more detail about sockets, doors,=
 etc.  I figure that would be a future RFE to add yet additional note secti=
ons (or possibly extending the NT_FDINFO with more information).  I think e=
ven without that information, the current data (which contains details abou=
t path, mode bits, open flags, etc.) is still very helpful for folks doing =
post-mortem debugging.  In particular, this is kernel state that is typical=
ly not available to folks debugging with traditional tools like gdb, dbx, o=
r even mdb.  (A cool follow on project might be to give those debuggers the=
 ability to parse this new note as well.  I'll leave it for someone more fa=
miliar with those tools.)

I've tested this pretty well on x86 systems, but I've not really tested thi=
s on SPARC.  Full testing should involve applying the patch, rebooting, and=
 then generating and testing cores  as well as live procfs attach based tes=
ts for pfiles.  Also, the new elfdump utility should be tested on sparc as =
well.  I'd be happy to hear about any one who wants to take the patch file =
above, test it out on sparc, and let me know.

The review is kind of juicy -- about 900 lines or so.  I'd really like to g=
et this integrated before *too* long though, so I'd appreciate meaningful a=
nd timely review feedback.  If you are going to plan on reviewing it, pleas=
e let me know, and give me an estimate of how long you'd like to review it.=
  Thanks!

Also, any testing (esp. sparc, but not *just* sparc) would be gratefully re=
ceived.

 - Garrett



-------------------------------------------
illumos-developer
Archives: https://www.listbox.com/member/archive/182179/=3Dnow
RSS Feed: https://www.listbox.com/member/archive/rss/182179/22406080-a3f15b=
b4
Modify Your Subscription: https://www.listbox.com/member/?member_id=3D22406=
080&id_secret=3D22406080-849724b2
Powered by Listbox: http://www.listbox.com