From owner-freebsd-hackers Thu Jun 27 02:02:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11850 for hackers-outgoing; Thu, 27 Jun 1996 02:02:11 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA11842 for ; Thu, 27 Jun 1996 02:02:04 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA02759; Thu, 27 Jun 1996 18:59:07 +1000 Date: Thu, 27 Jun 1996 18:59:07 +1000 From: Bruce Evans Message-Id: <199606270859.SAA02759@godzilla.zeta.org.au> To: alk@Think.COM, jkh@time.cdrom.com Subject: Re: longstanding, woeful inadeqacy Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >: Fork is an easier case since you don't need to swap the debugger's >: executable out - just attach to the new process. Erm. It might be easier because the pc is predictable and breakpoints in the program test don't go away. The debugger doesn't move. However, the kernel has better support for exec than for fork: the execed program "stops before executing the first instruction of the new image" (see ptrace(2)). This seems to work as well as can be expected. You have to load the symbols for the new image. >Easier in what sense? It is essentially impossible to debug anything >that forks, since by the time you can attach to it, it has gone >veering wildly out of control. The child process should probably stop too. It may be too late to fix this. Linux is said to have some syscall for stopping processes before (and after?) all syscalls. This could be used to keep control if it works right across fork/exec. strace probably needs it to work right across fork/exec to keep control. Bruce