Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
I don't think that "developer-centric" debugging is really even
remotely our problem, and that I'm personally a lot more interested
in infrastructure that helps normal users give better
bug-reports. And kgdb isn't even _remotely_ it.
-- Linus Torvalds, still not sold on kernel
debuggers.
I used kgdb continuously for 4-5 years until it broke. I don't
think I ever used it much for "debugging" as such. I used it more
for general observation of what's going on in the kernel.
-- Andrew Morton(Log in to post comments)
Quotes of the week Posted Feb 7, 2008 20:51 UTC (Thu) by johnny (guest, #10110) [Link] What's our editor's stance on kgdb; does he use it, or does it make him grumpy (or both)? ;-)
Quotes of the week Posted Feb 7, 2008 21:23 UTC (Thu) by jengelh (subscriber, #33263) [Link] Not having used kgdb makes one learn to write code more carefully over time. At least I have that impression.
Quotes of the week Posted Feb 7, 2008 23:11 UTC (Thu) by lutchann (subscriber, #8872) [Link] Generally I've found kernel debuggers to be most useful for finding bugs in other people's code...
kernel debuggers Posted Feb 9, 2008 21:35 UTC (Sat) by giraffedata (subscriber, #1954) [Link] It's the opposite for me. When somebody else's code has a bug, I can often just read the code and see where it doesn't do the right thing. When I wrote the code, I'll miss the bug on reading the code the same way I did when I wrote it. With the debugger, I have to understand the code intimately. I display a variable value or code path to see if it matches what I intended for it to be. With someone else's code, I don't really know what he intended a variable to mean or what code is supposed to run for what cases, so the debugger isn't much help. The only place the debugger is especially useful with somebody else's code is when I can't tell from reading the code which piece of it handles my case, so a trace points me to the piece that I need to read more closely.
Quotes of the week Posted Feb 9, 2008 23:58 UTC (Sat) by mattmelton (subscriber, #34842) [Link] Please don't read if easily trolled. I'm due a moan. Linux *needs* a decent kernel level debugger. Yes I know the ongoing fear of going microkernel by implementing such, but realistically, it's many times easier using a kernel debugger than a crawling virtual machine. Sometimes I feel Linus doesn't listen to normal people. People who actually frequent different code bases, projects and the kind of people who embrace a multitude of different skill sets (not always through desire). For example, some of us follow the money bug and others the academia bug. Normal people would embrace a wonderful IOKit-clone, built with C++ niceness (there's more than enough to embrace than balk at tyvm); but no, we hear quite regularly and without much debate an emphatic "sshpt, never." Personally, it's nicer to develop an IOKit driver for MacOS than it is a linux driver - second guessing a poorly created API to gain a hit/miss chance of cscope'ing the right one isn't a sound development method. Calling member functions is. Personally, I find it refreshing knowing that the addresses and deconstruction I'm getting is what's actually executed - not a best guess, post "fixed" version I cant step backwards and forwards in! It's very hard to say "I don't like it, but show me the money" and not cause a feature to fizzle out. When Linus stays on the side and expects some kind of proof, stating so clearly he's not interested/not going to help, it really does start the whole mental rail-roading process in his supporters. Didn't I read somewhere recently that Linus only really cares about the desktop? That made me terribly uncomfortable - more the knowing that it's so easy to say something and not believe it, than the sad realisation that one "yes/no" man with so much weight behind him can be a feature killer, hurting the developers that need him to progress the most. It's 2008 folks. Not 1991.
|
|||||||||||||