Date: Tue, 21 Nov 2006 14:56:32 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: trowa-4 <trowa-4@yahoo.com.tw>, Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= <des@des.no>, Jeremie Le Hen <jeremie@le-hen.org>, freebsd-hackers@FreeBSD.org Subject: Re: Process Debugging questions Message-ID: <20061121144831.Y63599@fledge.watson.org> In-Reply-To: <20061121154714.03vzlj72sss88k4c@webmail.leidinger.net> 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> <20061121115333.N50450@fledge.watson.org> <20061121150941.wlwmfw8u0w0c444k@webmail.leidinger.net> <20061121142005.T63599@fledge.watson.org> <20061121154714.03vzlj72sss88k4c@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Nov 2006, Alexander Leidinger wrote: > Quoting Robert Watson <rwatson@FreeBSD.org> (from Tue, 21 Nov 2006 14:21:59 > +0000 (GMT)): > >> On Tue, 21 Nov 2006, Alexander Leidinger wrote: >> >>> Quoting Robert Watson <rwatson@FreeBSD.org> (from Tue, 21 Nov 2006 >>> 11:55:37 +0000 (GMT)): >>> >>>> Anyone who wants to start looking at a new API should make sure they look >>>> at ptrace() and procfs across a range of platforms, and also look at Mach >>>> task ports and what they offer. One of the things we really can't do >>>> well with ptrace() today is inspect kernel state for a running process -- >>>> things like the VM layout, etc. We should make sure any next generation >>>> system allows this, because that feature alone is the reason why I >>>> sometimes mount procfs. :-) >>> >>> Can you please elaborate what features you have in mind which DTrace isn't >>> able to deliver? >> >> /proc/curproc/map > > With DTrace we have access to a lot of stuff. I think this is only a case of > writting the right dtrace script (intercepting malloc/free/sbrk/mmap/... > should allow for more sophisticated output). DTrace has access to some but not all of this information, and even then only if you've been tracing since inception. Part of the value of /proc/pid/map is that you can ask the question about process mappings at any time, even if you've only just decided it's interesting to ask; with DTrace you have to be tracing all along and know in advance that it's a question you're going to ask. DTrace on the user app also doesn't have access to kernel-generated mappings in the address space, such as the mappings created at exec()-time itself. We require two things, I think: - A correctly-written, well-implemented, thread and inheritable process aware debugging mechanism. This would allow querying the kernel for relevent state (thread lists, etc), setting breakpoints, allowing memory access, stepping the process, breaking on system call entry/exit (required for truss), and so on. It would not require the debugged process to be reparented or deliver events using waitpid. - A general mechanism for querying detailed kernel state about a process, such as its VM mappings, file descriptor state, etc. Things that aren't normal process monitoring stuff (i.e., require debugging privileges on the target process). Currently, procfs provides this combined facility. On Mac OS X, Mach task, thread, VM, etc ports provide this combined facility. I would like a system call driven mechanism with those facilities. I'm reluctant to stuff the latter half into sysctl as I prefer that sysctl generally hold mostly public information rather than having lots and lots of access control. Combining the functionality makes some amount of sense as both sets of functionality will tend to be used in debugging and may be useful in the same application. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061121144831.Y63599>