Ingo Molnar mi...@elte.hu writes:
[...] Since the speed of development in this area is truly glacial
at the moment and the practical advantages that i can experience
personally (directly as a Linux user and indirectly as a maintainer)
are miniscule so far, caution is warranted IMO. [...]
Hi -
On Thu, Dec 10, 2009 at 07:16:38PM +0100, Ingo Molnar wrote:
[...]
The gdbstub prototype was constructed for two reasons: to demonstrate
utrace usage now, and in the future to be incrementally useful (over
ptrace, by moving into fast kernel-space operations like
multithreading
* Frank Ch. Eigler f...@redhat.com wrote:
[...]
If the in-kernel gdb stub replaced kgdb functionally you'd hear no
complaints from me.
Let's leave it as an idea for the future.
We came a full circle - that's the argument. We say overlap, duplication
and incomplete implementation in
Hi -
Help me out here: by kgdb extension do you imagine something new
that an unprivileged user can use to debug his own process? Or do
you imagine a new userspace facility that single-steps the kernel?
Is this a trick question? Single-stepping the kernel on the same system
Hi -
On Tue, Dec 01, 2009 at 05:11:32PM +0100, Ingo Molnar wrote:
Those facilities are not overlapping with kgdb though so my point doesnt
apply to them. An in-kernel gdb server sure overlaps/extends kgdb
though.
Only in name. One is highly invasive, for debugging the kernel across
serial
* Frank Ch. Eigler f...@redhat.com wrote:
Hi -
Only in name. One is highly invasive, for debugging the kernel across
serial consoles. The other is highly noninvasive, for debugging user
processes across normal userspace channels. They both happen to talk
to gdb, but that's
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote:
This patch implements an in-kernel gdb stub.
It provides an interface between gdb and Linux Kernel by implementing
the remote serial protocol. This gdbstub uses utrace infrastructure.
This patch provides register set access, signal
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]:
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote:
This patch implements an in-kernel gdb stub.
It provides an interface between gdb and Linux Kernel by implementing
the remote serial protocol. This gdbstub uses utrace
On Mon, 2009-11-30 at 18:02 +0530, Srikar Dronamraju wrote:
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]:
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote:
This patch implements an in-kernel gdb stub.
It provides an interface between gdb and Linux Kernel by
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:41:47]:
This is a In-kernel gdbstub to debug user space programs.
This stub doesnt help in debugging kernel.
Hence I am not sure how to compare kgdb gdbstub with this gdbstub.
Can you please provide more pointers on what you were
On Mon, 2009-11-30 at 18:49 +0530, Srikar Dronamraju wrote:
This is suppose to be one of the interfaces to use utrace, i.e Allow
gdb to use utrace features without having to change gdb itself.
Though there are not enough features in this patch, intentions include
support multi-threaded
I guess Christoph, Roland and Frank would be able to explain in a better
fashion the rational and advantages of this stub over convential gdb.
Hmm,. wouldn't it make much more sense to extend the current kgdb stub
to include userspace debugging, providing an all-in-one solution?
I see
peterz wrote:
Hmm,. wouldn't it make much more sense to extend the current kgdb stub
to include userspace debugging, providing an all-in-one solution?
I think it would be much more powerful to be able to observe the full
software stack and not be limited by this user-kernel barrier.
There
* Frank Ch. Eigler f...@redhat.com wrote:
peterz wrote:
Hmm,. wouldn't it make much more sense to extend the current kgdb stub
to include userspace debugging, providing an all-in-one solution?
I think it would be much more powerful to be able to observe the full
software stack and
On Mon, Nov 30, 2009 at 04:16:50PM +0100, Ingo Molnar wrote:
[...]
kgdb exists here and today in the kernel and you cannot just build a
facility that doesnt replace it and doesnt integrate well with it.
Surely you don't mean that: every non-kgdb facility in the kernel
meets that definition,
15 matches
Mail list logo
