Re: Permanent Kgdb integration into the kernel - lets get with it.

[Jason Wessel <jason.wessel@windriver.com>]

Andi Kleen wrote:
> > Is there any movement on this?
>
> I'm open to reasonable patches for the hooks at least. If that is done
> then the actual kgdb code can be reviewed and considered eventually too. 
>
> But just having the hooks in would make it easy enough to use anyways 
> (no patching, just dropping in of new files, or even loading of it as a
> module into any kernel)
>
> When I did the original x86-64 kgdb port this worked nicely --
> kgdb could work with just the standard die notifiers and a simple
> change in the serial console code.
>
> The recent kgdb seems to need much more changes again though.
>
> However every time when I suggested this (fixing the hooks first
> and submitting the really needed changes piece by piece)
> there didn't seem to be any interest from the various kgdb maintainers.
>
> So my impression currently is that they're not interested in merging.
>
> Another problem is that kgdb is moving more and more away from
> mainline by adding various weird hacks and workarounds in random
> code that just make  merging harder.
>
> Before anything could be considered for merging that all would
> need to be cleaned up.
>
> -Andi
>   
Andi,

I too am open to having a API, for KGDB, but it does need more than just 
the trap vectors and the serial driver as hook points. There are a 
number of patches to fix problems randing from the NET_POLL API, NMI 
handling, and saving a bit more information when loading kernel modules.

If you have an API, that you would like to contribute or suggest, I for 
one am interested. I have long thought it would be nice to be able to 
choose between kernel debug tools KDB, KGDB, KEXEC etc... much like you 
can dynamically load I/O modules in KGDB and choose either RS232 or 
Ethernet after the kernel has booted.

At the current time, I am most certainly trying to consolidate the 
source forge KGDB patches, Tom Rini's branch, as well as my own 
development branch and hopefully Sergei's development branch as well. 
Perhaps after the code stream is stable you we can take a further look 
at what it takes to abstract a generic kernel debug interface. In the 
mean time if you have code or skeleton API proposal, I am definitely 
listening. It would be nice to have an in kernel soft single step API as 
an example, which could be leveraged by KGDB and utrace/ptrace, but that 
is a bit forward looking at this point.

Jason.