4 ms·

Kernel debuggers exist. Of course, we're all aware of Linus' opinion on the matter.

by vezzy-fnord 11y ago

serge2k 11y ago
I'm not, does he not like kernel debuggers or something?
- vezzy-fnord 11y ago
  "No" would be an understatement: https://lwn.net/2000/0914/a/lt-debugger.php3 https://lwn.net/2000/0914/a/lt-debugger.php3
  - 0xcde4c3db 11y ago
    He apparently softened somewhat on the issue and did eventually (2008 / 2.6.26) merge a debugger into mainline. I don't think he ever really had a good answer to Alan Cox pointing out that you can't always reason your way through hardware misbehavior.
    - carussell 11y ago
      His argument also necessarily presupposes that you're never going to use a debugger to root out latent bugs, that is, you're only using a debugger because you've just written some buggy code and and you're trying to figure out where the problem lies. Which is silly. There are bugs in the kernel right now, there were bugs when that was written (he even alludes to it, but seemingly fails to understand the implication of it), there will be bugs introduced in the future, and someone at some point might like to find those bugs. Some of the best "What is the worst bug you ever encountered?" war stories are cases where people end up narrowing things down to a bug in what they were previously treating as bedrock.
  - addicted 11y ago
    That's a really interesting post, and I'm glad I read it. I find myself agreeing with Linus quite a bit, and until now I did not realize that there is programming being done without step by step debugging. And I think Linus's claims that people would be more careful when first designing and writing code if they didn't have a debugger to help them going forward makes a lot of sense. Unfortunately I work with too many people whose approach to programming is "Read spec, code, debug why code isn't working to spec, fix that specific bug". Design, architecture, etc. are simply not part of the process. I can see how a lack of easy debugging may force some forethought into the development process. That being said, how valid would this be in a development environment (like the kernel) where a lot of the work you are doing is making changes designed and created by someone else? Linus says the solution is to make sure you were careful at the start. But what if you weren't even there at the start, and had to step in later?
    - vezzy-fnord 11y ago
      The point is his view about kernel debuggers is complete nonsense, and I'm baffled that you and so many others could ever take it seriously. Yes, people would be more careful without debuggers, the same way they'd be more careful with cooperative multitasking hanging the system when they forget to yield. That doesn't make it good.
      - serge2k 11y ago
        Quite often I read posts by Linus and find myself unable to take him seriously. He's arrogant, abrasive, and some of his opinions (security, debuggers apparently) are ridiculous.
        xorblurb 11y ago
        Honestly Linus is a genius about the social side of big projects. He managed to scale Linux development very well, even writing Git in the middle. About the technical parts in their epoch context, it is more mixed: technically before 2.6 versions the kernel had far too many architectural flaw to be considered for serious workloads (even if I enjoyed using it even from the 2.0 series); and today I actually don't know of a single programmer around me that think he is right about the approach of security. On the other hand he was one of the first high profile programmer to call the modern interpretation of C undefined behaviors by modern compiler writers insane. But at least the beginning technical shortcomings could be explained because Linux kernel hackers of that time were unexperimented, and they actually several times silently learned from (some) NT designs and/or maybe big Unixes of that epoch (probably mainly Solaris) and adapted them not a too long time after trolling about why their previous simpler one was good enough (when it was clearly not). The security approach today coming from people having work that long in the industry is inexplicable. (maybe it is just to early and they will just silently convert to reasonable opinions in 2016? :p )
        vacri 11y ago
        No, he's not. He is a little arrogant - it's hard to be such a significant tech lead without being so - but if you actually read what he writes, he's not actually that abrasive. What happens is that some sensationalist idiot will see Torvalds lose his patience and post an angry retort to someone, and post just that response to places like HN, completely out of context. I've lost count of the number of times it's happened here, when everyone's tutting about Torvalds' behaviour and how he's "so aggressive right out of the gate", when no-one looks at the thread history to see him being patient and explaining things. In any case, zero of the tech heads from Jobs on down satisfy your demands to be taken seriously. I really don't understand why Torvalds gets held to this higher standard of hippie-level friendliness when people don't expect the same from other major tech project managers. I mean hell, Jobs was adored for having opinions that people considered ridiculous.
  - serge2k 11y ago
    > And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. That's insane.
albinofrenchy 11y ago
Not all debug tools are single step debuggers. There are memory verifiers, formal proof techniques and self testing frameworks that Linux uses that are very, very useful
- xjia 11y ago
  What are those tools?
  - colin_mccabe 11y ago
    sparse -- adds annotations to kernel code which can be checked by the compiler. It is a little bit like a parallel type system which provides domain-specific knowledge like "this function takes lock A and then lock B" or "this function runs in interrupt context." See https://sparse.wiki.kernel.org/index.php/Main_Page https://sparse.wiki.kernel.org/index.php/Main_Page kmemcheck -- sort of like valgrind, but for the kernel. CONFIG_FAULT_INJECTION -- inject random faults at runtime (such as in memory allocation) to test infrequently encountered error paths. CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK -- run expensive mutex validation checks at runtime. coccinelle -- a source code matching and transformation engine. You can use it in some of the same contexts as sed or awk. Unlike those tools, it is aware of the C language so it can do smarter things like add an extra final argument to all occurrences of a call to do_foo_bar_baz(). See http://coccinelle.lip6.fr/ http://coccinelle.lip6.fr/ checkpatch.pl -- Checks a patch to see if it conforms to the kernel style guide. Simple things like enforcing 80-column lines, but also more complicated things as well like variable naming, whitespace, etc. smatch, flawfinder -- static analysis tools that are similar in principle to Coverity. Like Coverity, they are unsound, but often helpful.
    - xjia 11y ago
      Thanks for the summary. However, what do we have on the formal proof side?

Kernel debuggers exist. Of course, we're all aware of Linus' opinion on the matter.

serge2k 11y ago

I'm not, does he not like kernel debuggers or something?

vezzy-fnord 11y ago
"No" would be an understatement: https://lwn.net/2000/0914/a/lt-debugger.php3 https://lwn.net/2000/0914/a/lt-debugger.php3
- 0xcde4c3db 11y ago
  He apparently softened somewhat on the issue and did eventually (2008 / 2.6.26) merge a debugger into mainline. I don't think he ever really had a good answer to Alan Cox pointing out that you can't always reason your way through hardware misbehavior.
  - carussell 11y ago
    His argument also necessarily presupposes that you're never going to use a debugger to root out latent bugs, that is, you're only using a debugger because you've just written some buggy code and and you're trying to figure out where the problem lies. Which is silly. There are bugs in the kernel right now, there were bugs when that was written (he even alludes to it, but seemingly fails to understand the implication of it), there will be bugs introduced in the future, and someone at some point might like to find those bugs. Some of the best "What is the worst bug you ever encountered?" war stories are cases where people end up narrowing things down to a bug in what they were previously treating as bedrock.
- addicted 11y ago
  That's a really interesting post, and I'm glad I read it. I find myself agreeing with Linus quite a bit, and until now I did not realize that there is programming being done without step by step debugging. And I think Linus's claims that people would be more careful when first designing and writing code if they didn't have a debugger to help them going forward makes a lot of sense. Unfortunately I work with too many people whose approach to programming is "Read spec, code, debug why code isn't working to spec, fix that specific bug". Design, architecture, etc. are simply not part of the process. I can see how a lack of easy debugging may force some forethought into the development process. That being said, how valid would this be in a development environment (like the kernel) where a lot of the work you are doing is making changes designed and created by someone else? Linus says the solution is to make sure you were careful at the start. But what if you weren't even there at the start, and had to step in later?
  - vezzy-fnord 11y ago
    The point is his view about kernel debuggers is complete nonsense, and I'm baffled that you and so many others could ever take it seriously. Yes, people would be more careful without debuggers, the same way they'd be more careful with cooperative multitasking hanging the system when they forget to yield. That doesn't make it good.
    - serge2k 11y ago
      Quite often I read posts by Linus and find myself unable to take him seriously. He's arrogant, abrasive, and some of his opinions (security, debuggers apparently) are ridiculous.
      - xorblurb 11y ago
        Honestly Linus is a genius about the social side of big projects. He managed to scale Linux development very well, even writing Git in the middle. About the technical parts in their epoch context, it is more mixed: technically before 2.6 versions the kernel had far too many architectural flaw to be considered for serious workloads (even if I enjoyed using it even from the 2.0 series); and today I actually don't know of a single programmer around me that think he is right about the approach of security. On the other hand he was one of the first high profile programmer to call the modern interpretation of C undefined behaviors by modern compiler writers insane. But at least the beginning technical shortcomings could be explained because Linux kernel hackers of that time were unexperimented, and they actually several times silently learned from (some) NT designs and/or maybe big Unixes of that epoch (probably mainly Solaris) and adapted them not a too long time after trolling about why their previous simpler one was good enough (when it was clearly not). The security approach today coming from people having work that long in the industry is inexplicable. (maybe it is just to early and they will just silently convert to reasonable opinions in 2016? :p )
      - vacri 11y ago
        No, he's not. He is a little arrogant - it's hard to be such a significant tech lead without being so - but if you actually read what he writes, he's not actually that abrasive. What happens is that some sensationalist idiot will see Torvalds lose his patience and post an angry retort to someone, and post just that response to places like HN, completely out of context. I've lost count of the number of times it's happened here, when everyone's tutting about Torvalds' behaviour and how he's "so aggressive right out of the gate", when no-one looks at the thread history to see him being patient and explaining things. In any case, zero of the tech heads from Jobs on down satisfy your demands to be taken seriously. I really don't understand why Torvalds gets held to this higher standard of hippie-level friendliness when people don't expect the same from other major tech project managers. I mean hell, Jobs was adored for having opinions that people considered ridiculous.
- serge2k 11y ago
  > And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. That's insane.

albinofrenchy 11y ago

Not all debug tools are single step debuggers. There are memory verifiers, formal proof techniques and self testing frameworks that Linux uses that are very, very useful

xjia 11y ago
What are those tools?
- colin_mccabe 11y ago
  sparse -- adds annotations to kernel code which can be checked by the compiler. It is a little bit like a parallel type system which provides domain-specific knowledge like "this function takes lock A and then lock B" or "this function runs in interrupt context." See https://sparse.wiki.kernel.org/index.php/Main_Page https://sparse.wiki.kernel.org/index.php/Main_Page kmemcheck -- sort of like valgrind, but for the kernel. CONFIG_FAULT_INJECTION -- inject random faults at runtime (such as in memory allocation) to test infrequently encountered error paths. CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK -- run expensive mutex validation checks at runtime. coccinelle -- a source code matching and transformation engine. You can use it in some of the same contexts as sed or awk. Unlike those tools, it is aware of the C language so it can do smarter things like add an extra final argument to all occurrences of a call to do_foo_bar_baz(). See http://coccinelle.lip6.fr/ http://coccinelle.lip6.fr/ checkpatch.pl -- Checks a patch to see if it conforms to the kernel style guide. Simple things like enforcing 80-column lines, but also more complicated things as well like variable naming, whitespace, etc. smatch, flawfinder -- static analysis tools that are similar in principle to Coverity. Like Coverity, they are unsound, but often helpful.
  - xjia 11y ago
    Thanks for the summary. However, what do we have on the formal proof side?