Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.lang.c Subject: Re: ptrace & Re: Mark Williams csd Message-ID: <318@rlgvax.UUCP> Date: Tue, 1-Jan-85 23:01:16 EST Article-I.D.: rlgvax.318 Posted: Tue Jan 1 23:01:16 1985 Date-Received: Thu, 3-Jan-85 03:46:05 EST References: <344@rna.UUCP>, <14@axiom.UUCP> <4842@utzoo.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 18 > Actually, V8's "/proc" (a directory all of whose files actually refer to > system processes; open the file and reads and writes act on that process' > address space) seems like a much cleaner solution to the nasty > efficiency problems of ptrace, and it too is compatible. Well, *some* of the problems. V8 is based on 4.1BSD, so it assumes you have virtual memory available. If, on a machine which doesn't support virtual memory or partial loading of processes, process A is debugging process B, and process A and process B don't both fit into main memory, "/proc" and "ptrace" are both going to be horribly inefficient. I don't know how much V8's implementation of reads and writes on a process' address space depends on the kernel supporting virtual memory. I do agree that, if implementable, "/proc" is 1000% the right way to do things. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy