Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!oddjob!gargoyle!ihnp4!cbosgd!osu-cis!tut!tut.cis.ohio-state.edu!mumble@karl
From: karl@mumble.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <2593@tut.cis.ohio-state.edu>
Date: Wed, 2-Dec-87 08:34:25 EST
Article-I.D.: tut.2593
Posted: Wed Dec  2 08:34:25 1987
Date-Received: Sun, 6-Dec-87 02:15:24 EST
References: <10605@brl-adm.ARPA>
Sender: news@tut.cis.ohio-state.edu
Reply-To: karl@tut.cis.ohio-state.edu
Lines: 26
In-reply-to: weiser.pa@Xerox.COM's message of 1 Dec 87 17:02:17 GMT


weiser.pa@Xerox.COM writes:
   you
   simply may not know ahead of time that the program you are running
   will want to figure out where it is running from.  A /dev scheme
   will work ok, or a new system call "givemeanfdfromwhereIam
   running".

One of the research versions of UNIX at Murray Hill supports this.
It's implemented as an ioctl(2) (or was it an fcntl(2)?) against a
file descriptor.  This can be used in conjunction with /proc; you open
the /proc/pid special file for the process you want to see (using
atoi(getpid()) should do the trick to look at yourself), then issue
this ioctl() against that file descriptor; you get back a file
descriptor pointing to the original binary which was exec'd.

This is used in a debugger, where you give it the pid of the currently-
existing process to debug; the debugger opens /proc/that-pid, then
gets a hold of the symbol table for that program by using this new
ioctl.  The debugger never needed to know the name of the program file
being debugged, and the debugged program doesn't need to be a child of
the debugger, either.

I believe this was discussed in one of the papers in the Oct 1984 Bell
Labs Tech. Journal.
-=-
Karl