调试操作系统 [英] Debugging an Operating System

问题描述

我正在经历一些关于操作系统的一般事情，并提出了一个问题。在开发操作系统时，开发人员将如何进行调试，即调试操作系统本身？可以为OS开发人员调试哪些工具？

解决方案

调试内核是硬的，因为你可能不能依靠崩溃的机器沟通发生了什么此外，错误的代码可能在中断处理程序等可怕的地方。

有四种主要的调试操作系统的方法，我知道： p>

1. 健康检查以及屏幕输出。

   
   
   

   内核恐慌在Linux上（被称为糟糕））是一个很好的例子。 Linux人员写了一个功能，打印出他们可以找到的内容（包括堆栈跟踪），然后停止一切。

   
   
   

   甚至警告是有用的Linux可以在中断处理程序中意外去睡觉的情况下设置。例如， mutex_lock 功能会检查（在 might_sleep ）您是否处于不安全的环境中打印一个堆栈跟踪，如果你是。




2. 调试器

   
   
   

   传统上，在调试中，通过串行线路输出到稳定的测试机器。随着虚拟机的出现，您现在可以将一个虚拟机的执行串行线路连接到同一物理机上的另一个程序，这是非常方便的。然而，自然而然的是，这要求您的操作系统发布正在进行的操作并等待调试器连接。 KGDB （Linux）和 WinDBG （Windows）是一些这样的操作系统内调试器。 VMWare 明确支持这个故事。

   
   
   

   最近，那里的VM开发人员已经知道如何在没有串行线或内核扩展的情况下调试内核。 VMWare 已经在最近的内容中实施了这个。

   
   
   

   在操作系统中调试的问题（在我看来）与不确定性原则。中断（大多数硬错误肯定是）是异步的，频繁的和非确定性的。如果您的错误与特定方式的两个中断重叠，您将不会使用调试器公开它;这个bug可能甚至不会发生。也就是说，它可能，然后一个调试器可能是有用的。




3. 确定性重播

   
   
   

   你会收到一个似乎似乎出现在生产中的错误，你希望你可以记录发生了什么并重播，就像一个安全摄像头。感谢我在伊利诺伊州知道的教授，您现在可以在VMWare中执行此操作虚拟机。 VMWare和相关人员将其全部描述比我可以，他们提供了什么样的良好的文档。

   
   
   

   确定性重播是全新的现场，所以到目前为止，我不知道任何特别惯用的用途。他们说这对安全漏洞也应该特别有用。




4. 将所有内容移至用户空间。

   
   
   <最后，内核中的内容还是比较脆弱的，因此，遵循Nucleus（或Microkernel）设计，您可以将内核模式组件最小化到最低限度，从而具有巨大的开发优势。对于其他一切，您可以使用无数的用户空间开发工具，您会更快乐。 FUSE （用户空间文件系统扩展名）是 的典型示例。 / p>
   
   

   我喜欢这最后一个想法，因为这就像你写的程序是可写的。循环，否？

I was going through some general stuff about operating systems and struck on a question. How will a developer debug when developing an operating system i.e. debug the OS itself? What tools are available to debug for the OS developer?

解决方案

Debugging a kernel is hard, because you probably can't rely on the crashing machine to communicate what's going on. Furthermore, the codes which are wrong are probably in scary places like interrupt handlers.

There are four primary methods of debugging an operating system of which I'm aware:

1. Sanity checks, together with output to the screen.

   Kernel panics on Linux (known as "Oops"es) are a great example of this. The Linux folks wrote a function that would print out what they could find out (including a stack trace) and then stop everything.

   Even warnings are useful. Linux has guards set up for situations where you might accidentally go to sleep in an interrupt handler. The mutex_lock function, for instance, will check (in might_sleep) whether you're in an unsafe context and print a stack trace if you are.

2. Debuggers

   Traditionally, under debugging, everything a computer does is output over a serial line to a stable test machine. With the advent of virtual machines, you can now wire one VM's execution serial line to another program on the same physical machine, which is super convenient. Naturally, however, this requires that your operating system publish what it is doing and wait for a debugger connection. KGDB (Linux) and WinDBG (Windows) are some such in-OS debuggers. VMWare supports this story explicitly.

   More recently the VM developers out there have figured out how to debug a kernel without either a serial line or kernel extensions. VMWare has implemented this in their recent stuff.

   The problem with debugging in an operating system is (in my mind) related to the Uncertainty principle. Interrupts (where most of your hard errors are sure to be) are asynchronous, frequent and nondeterministic. If your bug relates to the overlapping of two interrupts in a particular way, you will not expose it with a debugger; the bug probably won't even happen. That said, it might, and then a debugger might be useful.

3. Deterministic Replay

   When you get a bug that only seems to appear in production, you wish you could record what happened and replay it, like a security camera. Thanks to a professor I knew at Illinois, you can now do this in a VMWare virtual machine. VMWare and related folks describe it all better than I can, and they provide what looks like good documentation.

   Deterministic replay is brand new on the scene, so thus far I'm unaware of any particularly idiomatic uses. They say it should be particularly useful for security bugs, too.

4. Moving everything to User Space.

   In the end, things are still more brittle in the kernel, so there's a tremendous development advantage to following the Nucleus (or Microkernel) design, where you shave the kernel-mode components to their bare minimum. For everything else, you can use the myriad of user-space dev tools out there, and you'll be much happier. FUSE, a user-space filesystem extension, is the canonical example of this.

   I like this last idea, because it's like you wrote the program to be writeable. Cyclic, no?

这篇关于调试操作系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！