Tom Tromey tro...@redhat.com writes:
* 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.
How would having a kernel based solution be
The problem is that anything that is based on reparenting and signals is
fundamentally a one parent only kind of interface. See?
I was actually thinking about that before I wrote the email.
But when I did that i couldn't come up with a good scenario
where multiple debuggers actually make
Simple example. Try to debug/strace strace ot gdb itself. Not trivial,
you can't attach to strace's tracees. Recently I spent 2 days trying to
understand why strace -f hangs. I was able to attach to strace, but
I wasn't able to see what its tracees do.
But what would the semantics be inside
Peter Zijlstra pet...@infradead.org writes:
With CPL2 or RPL on user segments the protection issue seems to be
manageable for running the instructions from kernel space.
Nope -- it doesn't work on 64bit and even on 32bit can have large
costs on some CPUs.
Also designing 32bit only features
This is subjective, but personally I disagree. Contrary, imho it
is good that tracehook hides the (simple) details. I do not understand
why the reader of, say, do_fork() should see the contents of
tracehook_report_clone_complete(). This will complicate the understanding.
Someone who has to
Oleg Nesterov o...@redhat.com writes:
From: Roland McGrath rol...@redhat.com
This adds the utrace facility, a new modular interface in the kernel
for implementing user thread tracing and debugging. This fits on top
of the tracehook_* layer, so the new code is well-isolated.
Could we just
On Tue, Nov 24, 2009 at 09:41:52PM +0100, Oleg Nesterov wrote:
On 11/24, Andi Kleen wrote:
Oleg Nesterov o...@redhat.com writes:
From: Roland McGrath rol...@redhat.com
This adds the utrace facility, a new modular interface in the kernel
for implementing user thread tracing
