Daniel Jacobowitz wrote:
On Tue, Jun 24, 2008 at 10:49:56PM -0400, Chris Moller wrote:I've been scratching my head for a bit on some other way to provide user-space access to utrace. Three things occurred to me:1. A systemtap-like approach. 2. A whole new syscall, SYS_utrace or some such. 3. An extension of ptrace.Extending ptrace seems like a sad idea. If Linux is going to grow a new userspace-accessible debug interface, can't it go in /proc or something?
Actually, that's exactly what utracer does. It's a module that creates an entries under /proc (/proc/utracer/*) that client apps can read()/write()/ioctl() to access utracer capabilities. Maybe the coolest thing about utracer is that it gave every app its own /proc entry that blocked on read() until an app-defined "interesting" thing happened: specified signals, task state changes, specified syscall entry/exit, all the stuff accessible through utrace report_* callbacks.
The single biggest pain in GDB's process management is dealing with signals, especially the ways that ptrace interferes with normal operation. But I don't have any context; I don't know what you're adding...
At least all the report_* stuff (current plan is something like a call to ptrace(UTRACE_WAIT,...) that blocks until one of the above interesting things happens, to be called from it's own thread), plus maybe breakpoint support and anything else utrace might provide in the future or will fit into the paradigm.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
