From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 21 08:57:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89B0C16A412 for ; Tue, 21 Nov 2006 08:57:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C466B43D58 for ; Tue, 21 Nov 2006 08:57:37 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6A9C12085; Tue, 21 Nov 2006 09:57:54 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 4EBA72083; Tue, 21 Nov 2006 09:57:53 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 953D7B85E; Tue, 21 Nov 2006 09:57:53 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Jeremie Le Hen References: <571883.4868.qm@web72011.mail.tp2.yahoo.com> <86irhlfvg2.fsf@dwp.des.no> <20061120221026.GC20405@obiwan.tataz.chchile.org> Date: Tue, 21 Nov 2006 09:57:53 +0100 In-Reply-To: <20061120221026.GC20405@obiwan.tataz.chchile.org> (Jeremie Le Hen's message of "Mon, 20 Nov 2006 23:10:26 +0100") Message-ID: <86d57hjhwu.fsf@dwp.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trowa-4 , freebsd-hackers@freebsd.org Subject: Re: Process Debugging questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2006 08:57:59 -0000 Jeremie Le Hen writes: > Dag-Erling Sm=F8rgrav writes: > > They both suck, for different reasons. In theory, ptrace sucks less > > than proc, but it lacks some of proc's functionality, and fixing that > > is very hard. > Would you take a little time to tell what ptrace lacks and possibly > why it is so hard, please ? The way ptrace works, you set debugging conditions using the ptrace(2) syscall and then use waitpid(2) and friends to wait for them to occur. For this to work, the traced process must be reparented to the debugger. If the traced process's real parent is waiting for its child, it will become very confused when waitpid(2) returns -1 because the child has vanished into thin air. For precisely the same reason, you can't follow forks with ptrace(). The only way I can see to solve this without modifying the ptrace API is to introduce a separate process hierarchy for traced processes. This is hard to do because you basically have to rewrite kern_wait() from scratch. The best solution would be to design a new debugging API from scratch. This is far from trivial, however, and should be done by (or in close cooperation with) someone intimately familiar with gdb(1) and similar tools. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no