Re: [RFC PATCH 0/4] utrace: new modular infrastructure for user debug/tracing

[Albert Cahalan]

Roland McGrath writes:

> This series of patches revamps the support for user process debugging
> from the ground up, replacing the old ptrace support completely.
>
> Two major problems with ptrace are its interface and its implementation.

Yay!

Having written a debugger for Linux, I can assure everyone that
this is long overdue. We've been putting it off for years because
the code is so horrible and nasty, yet not normally used prior to
the creation of user-mode Linux.

Doing serious work with ptrace() is a horrible joke involving
interfaces that are crufty, undocumented, and insufficient.

BTW: debuggers can't get and set the signal context (with cr2!),
can't get and set LDT entries, don't get events when unshare()
succeeds, can't call ptrace() from any desired thread, can't do
a stop or start that affects more than one task, can't adjust the
target's signal data (handlers,blocked,ignored,etc.), can't adjust
file pointers and flags in the target, etc.

With great difficulty, some of the above can be hacked around by
inserting code into the target and running it. This is horribly
painful. It puts writing a debugger out of reach of many people
who might otherwise have only very basic code insertion needs
or none at all.

> system call interface is clunky to use and to extend, and makes it
> difficult to reduce the overhead of doing several operations and of
> transferring large amounts of data.

See the FreeBSD ptrace() man page. We're just being dumb.

> There is no way for more than one
> party to trace a process.  The reporting model using SIGCHLD and wait4
> is tricky to use reliably from userland, and especially hard to
> integrate with other kinds of event loop.

We needlessly make wait4/waitid/waitpid fail to accept
equivalent flags. (some may need to be inverted sense)

We don't appear to have any way to get these events into a
select() or poll(). We could use this even for non-debugger apps.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/