[lkml]   [2010]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: add utrace tree

On Mon, 25 Jan 2010, Tom Tromey wrote:
> There are definitely things we would like from such an API. Here's a
> few I can think of immediately, there are probably others.
> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> Internally we're already using a self-pipe to integrate this into
> gdb's main loop. Relatedly, don't mess with the inferior's parentage.

As I kind of alluded to elsewhere, I heartily agree with this. The really
major design mistake of ptrace (as opposed to just various ugly corners)
is how it has no connection information, and that ends up being one of the
main reasons why you can't have two ptracers working on the same thing.

(There are other things that complicate that too, of course, like simply
just trying to manage various per-thread state like debug registers etc,
but that's a separate class of complications).

> * Support "displaced stepping" in the kernel; I think this would improve
> performance when debugging in non-stop mode.

Don't we already do that at least on x86? Just doing a single-step should
work on an instruction even if it has a breakpoint on it, because we set
the TF bit.

Or maybe I'm not understanding what displaced stepping means to you.

> * Support some kind of breakpoint expression in the kernel; this would
> improve performance of conditional breakpoints. Perhaps the existing
> gdb agent expressions could be used.

I suspect it might be reasonable to do simple expressions on breakpoints,
but not the kind of things gdb exports to users. IOW, maybe you could have
a single conditional on a single value (register or memory) associated
with an expression.

Regardless, internally to the kernel your two later issues are "details".
The "how to connect to the debuggee" is a much more fundamental issue, and
has the biggest design/interface impact. The other would likely just be
new ptrace command extensions that somebody would have to just implement
the grotty details on.


 \ /
  Last update: 2010-01-25 22:45    [W:0.148 / U:7.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site