Messages in this thread | | | Date | Tue, 5 Aug 2008 11:10:49 -0600 (MDT) | Subject | Re: [ANNOUNCE] Merkey's Kernel Debugger | From | jmerkey@wolfmoun ... |
| |
> That's great, except kgdb has existed in the kernel for various > architectures well before that as well. ppc32's stub dates back to 1998, > sh had it since 2001, mips around the same time, etc, etc. While the > current rework and tidying of the stubs is something new, kgdb itself is > not. > >> > 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 >> > tree and supported by a handful of architectures... any chance of >> > that? (I don't know kernel debugger code, so I ask as an interested >> > user) >> >> I plan to work on kdb and yes, there is a version of this that runs >> as an alternate debugger of kdb - you can even switch back and forth >> between them - but that misses the point as well. >> > kgdb and kdb are totally different things, kgdb is what is generally > available and worth improving in-kernel. > > While it's certainly good to have options, having multiple in-kernel > debuggers is not going to help matters for the vast majority of users. I > agree with Nick, it would be nice to see what we have in-kernel being > extended and worked on by more people, especially those with a background > in these things.
Not your call to make. Kernel Debuggers are very personal choices and its pure arrogance to assume any of us can make a choice for someone else with tools. My tastes in debuggers is like my tastes in food, or women, or what kin of toothbrush I like to use.
> > On the other hand, it seems like there's sufficient interest in your > project out-of-tree, so there's not really much point in merging it if > you're content with the interface as it exists today and it continues to > work for your users. > > One of the things we can do however is try to provide cleaner > abstractions for the various debuggers to tie in to, so we don't end up > with each debugger piling on its own set of ifdefs in all of the same > places (int3 handling comes to mind, which you could already do more > cleanly through the die chain today). Perhaps it would be more useful to > see what sort of hooks mdb wants in the architecture and core code, how > those overlap with kgdb, and how we might extend kgdb in areas where mdb > is more feature complete. >
This is a great suggestion. mdb already uses an alternate debugger interface with the hooks into traps_XX.c and reboot_XX.c. I still would like to see it in kernel. but an alternate debugger interface as you point out is almost a necessity at this point. there's a good example in mdb.c and mdb-list.c.
Jeff
| |