Process Debugging questions

[Robert Watson]

On Tue, 21 Nov 2006, Alexander Leidinger wrote:

> Quoting Robert Watson <rwatson at FreeBSD.org> (from Tue, 21 Nov 2006 14:21:59 
> +0000 (GMT)):
>
>> On Tue, 21 Nov 2006, Alexander Leidinger wrote:
>> 
>>> Quoting Robert Watson <rwatson at 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