dillon at apollo.backplane.com
Thu Oct 9 01:38:01 PDT 2003
:> the next step is to save and restore filesystem-based file descriptors
:> so as to reacquire the original text image. That's a fairly tough nut
:> to crack, but the result will be incredibly powerful.
:You're approach is much cleaner from the user's perspective in that it
:doesn't require the path to to the original binary. But mine was easier to
:implement as intermediate step. Oops, looking in /proc it appears that one
:can trivially get the path to the binary:
:> cd /proc/102/
:> ls -l file
:lr-xr-xr-x 1 root wheel 15 Oct 8 21:37 file -> /sbin/adjkerntz
:I'll see where this information is coming from and append it as a note
Probably textvp_fullpath() in kern/vfs_cache.c, but the function will
not dependably return the path. Only the device (or mount path) and
inode number is reliable enough.
Though... when the namecache stuff is done (it keeps getting delayed)
the paths *will* be dependable.
:after the program headers. It is a little harder to do this way because
:there is nothing in the elf header telling you how big the initial core
:file is. So I have to read the elf-header and then read through all the
:Elf_Phdrs before doing any real work.
:We're actually extremely close to having what you're talking about.
:It is largely a matter of cleanup.
:Thanks for your enthusiasm. I need it, as mine has waned as other things
:of interest (Xen) crop up. I will however polish it up over the next few
:days to the point where it can be checked in and used by others.
Xen sounds interesting but, fair warning :-), you are going to hit
some serious issues with hardware and device driver state.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel