Date: Tue, 21 Nov 2006 11:55:37 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: trowa-4 <trowa-4@yahoo.com.tw>, freebsd-hackers@freebsd.org, Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: Process Debugging questions Message-ID: <20061121115333.N50450@fledge.watson.org> In-Reply-To: <86d57hjhwu.fsf@dwp.des.no> References: <571883.4868.qm@web72011.mail.tp2.yahoo.com> <86irhlfvg2.fsf@dwp.des.no> <20061120221026.GC20405@obiwan.tataz.chchile.org> <86d57hjhwu.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1037187573-1164110137=:50450 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 21 Nov 2006, Dag-Erling Sm=F8rgrav wrote: > Jeremie Le Hen <jeremie@le-hen.org> writes: >> Dag-Erling Sm=F8rgrav <des@des.no> writes: >>> They both suck, for different reasons. In theory, ptrace sucks less th= an=20 >>> proc, but it lacks some of proc's functionality, and fixing that is ver= y=20 >>> hard. >> Would you take a little time to tell what ptrace lacks and possibly why = it=20 >> is so hard, please ? > > The way ptrace works, you set debugging conditions using the ptrace(2)=20 > syscall and then use waitpid(2) and friends to wait for them to occur. Fo= r=20 > this to work, the traced process must be reparented to the debugger. If = the=20 > traced process's real parent is waiting for its child, it will become ver= y=20 > confused when waitpid(2) returns -1 because the child has vanished into t= hin=20 > air. For precisely the same reason, you can't follow forks with ptrace()= =2E > > The only way I can see to solve this without modifying the ptrace API is = to=20 > introduce a separate process hierarchy for traced processes. This is hard= to=20 > do because you basically have to rewrite kern_wait() from scratch. > > The best solution would be to design a new debugging API from scratch. Th= is=20 > is far from trivial, however, and should be done by (or in close cooperat= ion=20 > with) someone intimately familiar with gdb(1) and similar tools. DES and I had precisely this discussion at EuroBSDCon a week or two ago, in= =20 which we both reminded each other why ptrace() and procfs both suck. I thi= nk=20 the right answer is an improved system call API for debugging; I agree that= =20 ptrace() is better in theory, but the practical problems with it are=20 significant. Anyone who wants to start looking at a new API should make sure they look a= t=20 ptrace() and procfs across a range of platforms, and also look at Mach task= =20 ports and what they offer. One of the things we really can't do well with= =20 ptrace() today is inspect kernel state for a running process -- things like= =20 the VM layout, etc. We should make sure any next generation system allows= =20 this, because that feature alone is the reason why I sometimes mount procfs= =2E=20 :-) Robert N M Watson Computer Laboratory University of Cambridge --0-1037187573-1164110137=:50450--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061121115333.N50450>