Message-ID: <4899DD9F.6020007@windriver.com>
Date:	Wed, 06 Aug 2008 12:21:35 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Andi Kleen <andi@...stfloor.org>, jmerkey@...fmountaingroup.com
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

Andi Kleen wrote:
> Nick Piggin <nickpiggin@...oo.com.au> writes:
>> Seriously? Because it doesn't seem to have had enough peer review,
>> it hasn't had widespread testing in somewhere like linux-next or
>> -mm, and we already have kgdb so you have to also explain why you
>> can't improve kgdb in the areas it trails mdb.
>>
>> But the ideal outcome would be if you could contribute patches to
>> kgdb to the point where it is as good as mdb. It is already in the
>
> I don't think kgdb and a simple assembler debugger
> are directly comparable. kgdb always requires a remote machine,
> which has many advantages, but is also often very inconvenient
> or impossible to arrange. An low overhead assembler debugger
> can be always compiled in just in case.
>

It depends how you look at the problem.  I would agree that the use of
gdb + kgdb vs an assembly debugger are completely different cases.
The kgdb core in the mainline kernel, can actually allow to write such
a front end however.  The kgdb core has an API for I/O and it is
possible to write an I/O module that implements an in kernel assembly
debugger.  The kgdb test suite is not a great example, but it is a
complete example of using the kgdb core directly without a second
machine.

If there is truly missing functionality from kgdb in terms of the way
the kgdb core is used vs mdb, it would be good to at least consider
what is missing.  It is entirely possible to add functionality such
that mdb could be implemented a kgdb I/O module.  In this case you
would be able to make use of zero runtime impact when a kgdb I/O
module is not configure or make use of it as an early/late/ondemand
debugger.

> Also at least for the x86 port the debugger interfaces should
> be general enough now (see die hooks as a "debug vfs") that it would
> be quite possible to have a multitude of debuggers just using
> them. In fact that's already the cases, kprobes and kgdb and
> kdump are all kinds of debuggers using such hooks.
>

I would agree that the possibility exists to use the hooks directly,
and clearly the mdb code base as it stands in this patch set does not
accomplish this.

If one were to consider integrating mdb as a kgdb I/O module, it would
have a greater degree of platform independence.  The primary arch
dependencies should be narrowed down to the back tracing / disassembly
interface. The SMP / threading / breakpoints / exception handling,
would all be shared between the debugger front ends that way.  The mdb
code base currently relies on re-implementing HW/SW breakpoints for
each architecture you desire to support.

Unifying some of the debugging technology is a noble goal where it
makes sense to do so.  Using some of the existing kernel hook points
is a first pass requirement before a merge of mdb could be considered
for the mainline kernel.

Jason.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists