Re: Process Debugging questions


On Tue, 21 Nov 2006, Alexander Leidinger wrote:

Quoting Robert Watson <rwatson@xxxxxxxxxxx> (from Tue, 21 Nov 2006 14:21:59 +0000 (GMT)):

On Tue, 21 Nov 2006, Alexander Leidinger wrote:

Quoting Robert Watson <rwatson@xxxxxxxxxxx> (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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Process Debugging questions
    ... 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, ... 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? ...
    (freebsd-hackers)
  • Re: Displaying system call buffers with dtrace?
    ... Dtrace is messy when the pointers are different lengths. ... I'm debugging ...
    (comp.unix.solaris)