Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: To find out the names of open files in a process
Summary: easier way
Message-ID: <558@cresswell.quintus.UUCP>
Date: 21 Jan 88 09:06:10 GMT
References: <2346@mandrill.CWRU.Edu> <339@tandem.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 48

In article <339@tandem.UUCP>, narayan@tandem.UUCP (narayan mohanram TCP/IP Conso) writes:
> In article <2346@mandrill.CWRU.Edu>, garg@mandrill.CWRU.Edu (Dev Datt Garg) writes:
> > 
>  One of the features I am trying 
> > to add is to be able to save the context of a process at any point in the 
> > user program, so that at later stage program can be restarted from that point.
> > I have got some success in doing that. I am having a problem, If the program,
> > which I am debugging has some files open. I am unable to know which files were
> >  open, so that the status of those files can be restored.
> 
There is a moderately straightforward method which doesn't involve kernel
hacking.  Basically, the original poster has
    {revised GNU debugger}
			 \
			  {child process}
and wants to maintain, in the debugger, a table
    {child's file descriptor number} --> {symbolic file name}.

The answer is simple:
	The child already contains stubs for all the system calls it
	uses.
	The debugger knows which system calls can allocate and
	deallocate file descriptors.
	The debugger places special break-points on each appropriate
	stub (it has the symbol table for the child, so knows where
	all the stubs are).  Note that you have to track chdir() too!

The debugger initialises its table when it starts the child.
(I don't know the GNU debugger, but presumably you can say e.g.
	run <input >output 2>error 12<another-file
and the debugger knows perfectly well which fd goes with what
symbolic file name at this point, because it put them there.)
Then, whenever the child executes open() or whatever, the debugger
adds the appropriate entry to its table, and whenever the child
executes close() or whatever, the debugger deletes the corresponding
entry from its table.

None of this requires the debugger to know anything that a debugger
doesn't have to know anyway, nor does it require special devices or
system calls not already provided or not available to ordinary users.
In fact, apart from ptrace() as such, it isn't even UNIX-specific.

There is a problem, of course:  what happens if a file has been deleted,
renamed, or otherwise altered since the checkpoint was saved?  But this
approach is actually better than scanning the disc, because although a
file can have any number of names in UNIX, with this approach you know
>>the name the child used<<.  So if something has gone wrong, at least
the user stands a chance of identifying the file name.