Path: utzoo!attcan!uunet!lll-winken!arisia!sgi!shinobu!odin!norge.sgi.com!jeffd
From: jeffd@norge.sgi.com (Jeff Doughty)
Newsgroups: comp.sys.sgi
Subject: Re: digging out stuff from process address space
Message-ID: <266@odin.SGI.COM>
Date: 28 Jul 89 20:35:15 GMT
Sender: news@odin.SGI.COM
Reply-To: jeffd@norge.sgi.com (Jeff Doughty)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 49



I can answer two of the three questions.  Perhaps one of my colleagues can
answer #1.

> q2: (problem) What magic do I need to read the top of user stack through
> 	/debug/<pid>?  I tried the following sequence:
> 
> 		fd = open("/debug/<pid>", 0);
> 		fcntl(fd, DFCSTOP, 0);
> 		nfd = fcntl(fd, DFCOPENT, x);
> 		lseek(nfd, stackbas(some low number), 0)
> 		read(nfd, buf, sizeof buf)
> 		fcntl(fd, DFCRUN, &(something which is CLEARNOSIG))

This is almost correct.  The problem is that you are reading the wrong file
descriptor.  DFCOPENT returns the file descriptor of the file that contains
the binary.  For example, if you are running "/usr/tmp/prog", the file
descriptor returned is as if your code said open("/usr/tmp/prog", 0).
This is of interest to debuggers who need symbol tables, but you are
interested in reading from the running process.  So read from fd, not nfd.

> q3: (curiosity) What is the reason to require the process to be stopped
> 	before doing DFCOPENT or read() from it?  This limits the usefulness
> 	of the operations provided.

This is due to a sticky implementation issue - I'll try to explain briefly.
Our kernel works on multiprocessors as well as uniprocessors.  Therefore
shared data must be protected from simultaneous access, which implies a lock
of some kind.  If an arbitrary process was to examine the address space of
another processor, the structures that hold this information would have to
be locked.  Well, in 99.9% of the time, this data is private to the process,
and need not be locked.  It needs only to be protected when dbx (which is
the primary user of /debug) is debugging the process.  By stopping a process,
we don't need locks since you know that the data structures aren't going to
be mucked with. In addition, it is arguably desirable that the process be
stopped when being examined by the debugger.

In the future, we may be relaxing this restriction by only locking when
modifying the virtual address space - a relatively infrequent event.
In the meantime, your code above is correct - stop the process and restart it.

> Thanks for any info

> rayan

Hope this helps.

					Jeff Doughty