Re: [PATCH 0/39] NLKD - Novell Linux Kernel Debugger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andi Kleen wrote:

"Randy.Dunlap" <[email protected]> writes:

On Wed, 9 Nov 2005, Jeff Garzik wrote:

Jan Beulich wrote:
The following patch set represents the Novell Linux Kernel Debugger,
stripped off of its original low-level exception handling framework.
Honestly, just seeing all these code changes makes me think we really
don't need it in the kernel.  How many "early" and "alternative" gadgets
do we really need just for this thing?
On the surface I have to agree.  However, if Jan wants feedback
on the patches, that's a reasonable request IMO.
(but they need to be readable via email so that someone
can comment on them)

At a quick blush, I would guess it has as much chance as
kdb does (or did) for merging.

I hope we can follow the same strategy as I did for debuggers on x86-64 - which imho worked very well. Get all the (sane) hooks in so that everybody who wants to use their particular flavour of debugger can use it by (ideally) either just loading it or alternatively applying a small
core patch and the debugger files elsewhere. The die chains started
from that.
Yes. This is the way to go. Use kdb as a base and instrument an alternate debugger interface. You need to also find a good way to allow GDB to work properly with alternate debuggers. At present, the code in traps.c is mutually exclusive since embedded int3
breakpoints trigger in the kernel for gbd. This is busted.

Jeff

Making the debugger work modular is a bit more work, but possible (was
done for kdb at least before with some changes). IMHO that's the ideal
state for users - they can just compile it externally and load it when
they need it, but the core kernel doesn't need to carry it. It
conflicts a bit with the usual policy of not exporting stuff that's
not used in the core kernel; but I think making an exception here is
reasonable because

So I guess it's best to concentrate on merging the hooks needed in a sane
way.
I think the many additions for "early" code in the NLKD patchkit
comes from Jan's desire to make the debugger work in as many weird
corner cases as possible. I must say he found a lot of problems in corner cases during that work in x86-64 and i386, fixing generic
bugs and making even the standard oops code and other error handling
code (e.g. double faults on i386) more reliable, which I appreciate.
The particular early changes have to be weighted of course in
intrusiveness. If it's simple and not too ugly stuff I guess it is
reasonable to consider it. If not the debugger will have
to live without it.

I already merged all the changes that looked good (and where I was cc'ed) for x86-64 now. Some patches need changes, and I guess with that
feedback the i386 part can be similarly adjusted.

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


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux