smk@axiom.UUCP (Steven M. Kramer) (12/27/84)
I don't know of ANY UNIX debugger that handles tracing/history/single
stepping quickly. This is because ptrace() is so slow! For each
read/write/execution of the child it has to do a context switch. When
you need to read the stack or rearrange breakpoints this can be very
slow, especially if the debugger doesn't optimize the places to single
step.
What we have done here, and I hope this can be adopted as a UNIX standard
is to ass a new form of ptrace request that takes an array of requests in
a buffer (pointed to by the addr parameter), the amt of which is stored in
data. All the ptraces are done at once and the status code is returned for
each in the buffer.
Real benefits come in that there is only one context switch that need occur,
which is great if swapping is done.
Let's think of putting this in into UNIXs of the future. It's prolonging the
ptrace rather than a more comprehensive construct (like an ioctl), but at
least it's compatible and it runs like a bat out of hell.
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)henry@utzoo.UUCP (Henry Spencer) (12/30/84)
Actually, V8's "/proc" seems like a much cleaner solution to the nasty
efficiency problems of ptrace, and it too is compatible.
(For those who haven't heard about /proc [where've you been?!?], the
basic notion is that there is a magic /proc directory -- actually just
a figment of the file system's imagination -- which contains "files"
each of which is the virtual memory of a currently-running process.
Subject to the usual issues of permissions etc., you can read and write
them using the ordinary system calls. There are a few ioctls you can
use to accomplish the odder ptrace operations. I think there may be a
paper about it in the "Unix Revisited" BLTJ.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryguy@rlgvax.UUCP (Guy Harris) (01/02/85)
> 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
henry@utzoo.UUCP (Henry Spencer) (01/03/85)
> ... 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. Not having had a close look at the innards of V8, I couldn't say. The problem you raise is equally applicable to ptrace, though, as you point out. If you ignore existing implementations and think about starting from scratch, then one would appear to be no harder than the other. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry