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