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

[jmerkey <jmerkey@utah-nac.org>]

Andi Kleen wrote:

> "Randy.Dunlap" <rdunlap@xenotime.net> 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/