blocks|key|1497684|text|调试器如何工作的细节将取决于您正在调试的是什么，以及操作系统是什么。对于Windows上的本机调试，您可以在MSDN：Win32+Debugging+API上找到一些详细信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1497685|用户通过名称或进程ID告诉调试器要附加到哪个进程。如果是一个名称，则调试器将查找进程ID，并通过系统调用启动调试会话；在Windows下，这将是DebugActiveProcess。|1497686|一旦附加，调试器将进入事件循环，这与任何UI很相似，但操作系统将根据正在调试的进程中发生的事件生成事件，而不是来自窗口系统的事件-例如，发生异常。参见WaitForDebugEvent。|1497687|调试器能够读取和写入目标进程的虚拟内存，甚至可以通过操作系统提供的API调整其寄存器值。请参阅适用于Windows的debugging+functions列表。|1497688|调试器能够使用符号文件中的信息将地址转换为源代码中的变量名称和位置。符号文件信息是一组单独的API，并不是操作系统的核心部分。在Windows上，这是通过Debug+Interface+Access+SDK实现的。|1497689|如果您正在调试托管环境(.NET、Java等)该过程通常看起来类似，但细节不同，因为虚拟机环境提供的是调试API，而不是底层操作系统。|1497690|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms809754.aspx|1|http://msdn.microsoft.com/en-us/library/ms679295(VS.85).aspx)|2|http://msdn.microsoft.com/en-us/library/ms681423(VS.85).aspx)|3|http://msdn.microsoft.com/en-us/library/ms679303(VS.85).aspx|4|http://msdn.microsoft.com/en-us/library/x93ctkx8.aspx^0|1N|J|0|0|20|I|1|0|23|H|2|0|1M|J|3|0|25|Q|4|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|H|3|I|5|6|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]]|C|$]]|$1|J|3|K|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|L|3|M|5|6|7|1N|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]|V|$5|Q|R|S|C|$T|W]]|X|$5|Q|R|S|C|$T|Y]]|Z|$5|Q|R|S|C|$T|10]]|11|$5|Q|R|S|C|$T|12]]]]

The details of how a debugger works will depend on what you are debugging, and what the OS is. For native debugging on Windows you can find some details on MSDN: <a href="http://msdn.microsoft.com/en-us/library/ms809754.aspx" rel="noreferrer">Win32 Debugging API</a>.

The user tells the debugger which process to attach to, either by name or by process ID. If it is a name then the debugger will look up the process ID, and initiate the debug session via a system call; under Windows this would be <a href="http://msdn.microsoft.com/en-us/library/ms679295(VS.85).aspx" rel="noreferrer">DebugActiveProcess</a>.

Once attached, the debugger will enter an event loop much like for any UI, but instead of events coming from the windowing system, the OS will generate events based on what happens in the process being debugged – for example an exception occurring. See <a href="http://msdn.microsoft.com/en-us/library/ms681423(VS.85).aspx" rel="noreferrer">WaitForDebugEvent</a>.

The debugger is able to read and write the target process' virtual memory, and even adjust its register values through APIs provided by the OS. See the list of <a href="http://msdn.microsoft.com/en-us/library/ms679303(VS.85).aspx" rel="noreferrer">debugging functions</a> for Windows.

The debugger is able to use information from symbol files to translate from addresses to variable names and locations in the source code. The symbol file information is a separate set of APIs and isn't a core part of the OS as such. On Windows this is through the <a href="http://msdn.microsoft.com/en-us/library/x93ctkx8.aspx" rel="noreferrer">Debug Interface Access SDK</a>.

If you are debugging a managed environment (.NET, Java, etc.) the process will typically look similar, but the details are different, as the virtual machine environment provides the debug API rather than the underlying OS.

blocks|key|1712794|text|我的理解是，当您编译应用程序或DLL文件时，无论它编译成什么，都包含代表函数和变量的符号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1712795|当您有一个调试版本时，这些符号比它是一个发布版本时要详细得多，因此允许调试器为您提供更多信息。当您将调试器附加到进程时，它会查看当前正在访问哪些函数，并从这里解析所有可用的调试符号(因为它知道编译文件的内部结构是什么样子，所以它可以确定内存中可能存在的内容，以及整数、浮点数、字符串等的内容)。就像第一张海报上说的那样，这些信息以及这些符号是如何工作的，很大程度上取决于环境和语言。|1712796|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My understanding is that when you compile an application or DLL file, whatever it compiles to contains symbols representing the functions and the variables.

When you have a debug build, these symbols are far more detailed than when it's a release build, thus allowing the debugger to give you more information. When you attach the debugger to a process, it looks at which functions are currently being accessed and resolves all the available debugging symbols from here (since it knows what the internals of the compiled file looks like, it can acertain what might be in the memory, with contents of ints, floats, strings, etc.). Like the first poster said, this information and how these symbols work greatly depends on the environment and the language.

blocks|key|1712825|text|在Linux中，调试进程是从ptrace(2)系统调用开始的。关于如何使用ptrace实现一些简单的调试构造，This+article有一个很好的教程。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1712826|entityMap|0|LINK|mutability|MUTABLE|url|http://linux.die.net/man/2/ptrace|1|http://www.linuxjournal.com/article/6100^0|11|6|E|9|0|1J|C|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]|$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

In Linux, debugging a process begins with the <a href="http://linux.die.net/man/2/ptrace" rel="noreferrer">ptrace(2)</a> system call. <a href="http://www.linuxjournal.com/article/6100" rel="noreferrer">This article</a> has a great tutorial on how to use <code>ptrace</code> to implement some simple debugging constructs.

blocks|key|1712890|text|了解调试的另一个有价值的来源是英特尔CPU手册(英特尔®64与IA-32架构软件开发人员手册)。在第3A卷的第16章中，介绍了调试的硬件支持，如特殊异常和硬件调试寄存器。以下是该章节中的内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1712891|T(陷阱)标志，TSS+-当试图切换到在其TSS中设置了T标志的任务时，生成调试异常(#DB)。|1712892|我不确定Window或Linux是否使用此标志，但阅读本章非常有趣。|1712893|希望这对某些人有帮助。|1712894|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Another valuable source to understand debugging is Intel CPU manual (Intel® 64 and IA-32 Architectures
Software Developer’s Manual). In the volume 3A, chapter 16, it introduced the hardware support of debugging, such as special exceptions and hardware debugging registers. Following is from that chapter:

T (trap) flag, TSS — Generates a debug exception (#DB) when an attempt is
made to switch to a task with the T flag set in its TSS.

I am not sure whether Window or Linux use this flag or not, but it is very interesting to read that chapter.

Hope this helps someone.

blocks|key|1497907|text|据我所知：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1497908|对于x86上的软件断点，调试器用CC+(int3.这是在Windows上使用WriteProcessMemory完成的。当CPU到达该指令并执行int3时，这会导致CPU生成调试异常。OS接收到此中断，意识到进程正在被调试，并通知调试器进程命中断点。|offset|length|style|CODE|1497909|命中断点并停止进程后，调试器将在其断点列表中查找，并将CC替换为最初存在的字节。调试器在EFLAGS中设置TF,+the+Trap+Flag+(通过修改CONTEXT)，并继续该过程。陷阱标志使中央处理器在下一条指令上自动生成单步异常(INT+1)。|1497910|当正在调试的进程下一次停止时，调试器再次将断点指令的第一个字节替换为CC，然后该进程继续。|1497911|我不确定是否所有调试器都是这样实现的，但我已经编写了一个Win32程序，它可以使用这种机制进行自我调试。完全没用，但很有教育意义。|1497912|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/INT_(x86_instruction%2529#INT_3)|1|http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674.aspx|2|http://en.wikipedia.org/wiki/INT_(x86_instruction)#INT_3)|3|http://en.wikipedia.org/wiki/FLAGS_register|4|http://en.wikipedia.org/wiki/Trap_flag|5|http://msdn.microsoft.com/en-us/library/windows/desktop/ms679284.aspx|6|http://en.wikipedia.org/wiki/BIOS_interrupt_call#Interrupt_table^0|0|G|2|K|4|12|I|20|4|K|4|0|12|I|1|20|4|2|0|R|2|18|6|1H|2|24|7|3A|5|18|6|3|1H|H|4|24|7|5|3A|5|6|0|Y|2|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]]|9|@$D|1H|E|1I|1|1J]|$D|1K|E|1L|1|1M]|$D|1N|E|1O|1|1P]]|A|$]]|$1|H|3|I|5|6|7|1Q|8|@$D|1R|E|1S|F|G]|$D|1T|E|1U|F|G]|$D|1V|E|1W|F|G]|$D|1X|E|1Y|F|G]|$D|1Z|E|20|F|G]]|9|@$D|21|E|22|1|23]|$D|24|E|25|1|26]|$D|27|E|28|1|29]|$D|2A|E|2B|1|2C]]|A|$]]|$1|J|3|K|5|6|7|2D|8|@$D|2E|E|2F|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|2G|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|2H|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]|X|$5|Q|R|S|A|$T|Y]]|Z|$5|Q|R|S|A|$T|10]]|11|$5|Q|R|S|A|$T|12]]|13|$5|Q|R|S|A|$T|14]]|15|$5|Q|R|S|A|$T|16]]]]

As I understand it:

For software breakpoints on x86, the debugger replaces the first byte of the instruction with <code>CC</code> (<a href="http://en.wikipedia.org/wiki/INT_(x86_instruction)#INT_3" rel="noreferrer"><code>int3</code></a>). This is done with <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674.aspx" rel="noreferrer"><code>WriteProcessMemory</code></a> on Windows. When the CPU gets to that instruction, and executes the <a href="http://en.wikipedia.org/wiki/INT_(x86_instruction)#INT_3" rel="noreferrer"><code>int3</code></a>, this causes the CPU to generate a debug exception. The OS receives this interrupt, realizes the process is being debugged, and notifies the debugger process that the breakpoint was hit.

After the breakpoint is hit and the process is stopped, the debugger looks in its list of breakpoints, and replaces the <code>CC</code> with the byte that was there originally. The debugger sets <a href="http://en.wikipedia.org/wiki/Trap_flag" rel="noreferrer"><code>TF</code>, the Trap Flag</a> in <a href="http://en.wikipedia.org/wiki/FLAGS_register" rel="noreferrer"><code>EFLAGS</code></a> (by modifying the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms679284.aspx" rel="noreferrer"><code>CONTEXT</code></a>), and continues the process. The Trap Flag causes the CPU to automatically generate a single-step exception (<a href="http://en.wikipedia.org/wiki/BIOS_interrupt_call#Interrupt_table" rel="noreferrer"><code>INT 1</code></a>) on the next instruction.

When the process being debugged stops the next time, the debugger again replaces the first byte of the breakpoint instruction with <code>CC</code>, and the process continues.

I'm not sure if this is exactly how it's implemented by all debuggers, but I've written a Win32 program that manages to debug itself using this mechanism. Completely useless, but educational.

I keep wondering how does a debugger work? Particulary the one that can be 'attached' to already running executable. I understand that compiler translates code to machine language, but then how does debugger 'know' what it is being attached to?

How does a debugger work?

软件开发

虚拟机

编译器

调试器

Windows

Linux

Java

我一直想知道调试器是如何工作的？特别是可以‘附加’到已经运行的可执行文件上的那个。我知道编译器会将代码翻译成机器语言，但是调试器如何“知道”它所附加的是什么呢？

问调试器是如何工作的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问调试器是如何工作的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问调试器是如何工作的？
EN