On Thu, 21 Jan 2010 21:51:13 +0100
Oleg Nesterov o...@redhat.com wrote:
On 01/07, Roland McGrath wrote:
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
On Fri 2010-01-22 08:43:18, valdis.kletni...@vt.edu wrote:
On Fri, 22 Jan 2010 10:51:39 +0530, Ananth N Mavinakayanahalli said:
FWIW, Oleg's implementation of ptrace over utrace is 100% compatible
with legacy ptrace; gdb testsuite indicates that
(http://lkml.org/lkml/2009/12/21/98).
On Mon, Jan 25, 2010 at 01:41:57PM -0800, Linus Torvalds wrote:
On Mon, 25 Jan 2010, Tom Tromey wrote:
...
* 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
Hi -
On Mon, Jan 25, 2010 at 02:05:54PM -0700, Tom Tromey wrote:
[...]
Nevertheless, if the Linux kernel were to present a new user-space API,
and if it had an advantage over ptrace, then we would port GDB to use
it. There are other platforms where, IIRC, we now use some /proc thing
instead
On Mon, Jan 25, 2010 at 04:07:21PM -0800, Linus Torvalds wrote:
On Tue, 26 Jan 2010, Renzo Davoli wrote:
The solution is that everybody can code his/her optimized kernel/user
interface for tracing in his/her kernel module, i.e. utrace.
I don't think people understand. That is simply
On Tue, 26 Jan 2010, Johannes Stezenbach wrote:
1. If you'd merge utrace + ptrace-on-utrace, but never anything else
which uses the utrace API, wouldn't it still be an improvement?
I already said earlier that I'd be perfectly happy to merge utrace code,
as long as it was clear that I'm
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
On Tue, 26 Jan 2010, Andi Kleen wrote:
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
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
On 01/26, Linus Torvalds wrote:
The problem is that anything that is based on reparenting and signals is
fundamentally a one parent only kind of interface. See?
Indeed. signals + do_wait() is the horrible model.
So the reason I think using an fd is a good idea is _not_ because gdb
already
On 01/26, Andi Kleen wrote:
But when I did that i couldn't come up with a good scenario
where multiple debuggers actually make sense. In a sense
being a debugger is really a very intimate thing for process. Do you
really want to have multiple of them messing with each other?
If yes how
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
Linus == Linus Torvalds torva...@linux-foundation.org writes:
Tom * Support displaced stepping in the kernel; I think this would improve
Tom performance when debugging in non-stop mode.
Linus Don't we already do that at least on x86?
I don't know. If it does, and gdb does not yet use that,
Tom * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
Tom Internally we're already using a self-pipe to integrate this into
Tom gdb's main loop. Relatedly, don't mess with the inferior's parentage.
Andi How would having a kernel based solution be better over your
Andi user
On 01/26, Andi Kleen wrote:
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
On Tue, 26 Jan 2010, Tom Tromey wrote:
In non-stop mode (where you can stop one thread but leave the others
running), gdb wants to have the breakpoints always inserted. So,
something must emulate the displaced instruction.
I'm almost totally uninterested in breakpoints that actually
tromey wrote:
[...]
In non-stop mode (where you can stop one thread but leave the others
running), gdb wants to have the breakpoints always inserted. So,
something must emulate the displaced instruction.
This sounds like the sort of thing that kernel kprobes do, which the
uprobes patch
17 matches
Mail list logo
