Google Breakpad之五，处理器设计

E文-》http://code.google.com/p/google-breakpad/wiki/ProcessorDesign

Breakpad Processor 库

目标

Breakpad processor library是一个处理多平台崩溃的dump的框架，用于显示每个线程调用链的堆栈信息。处理后，数据变为对库使用者可用的数据。

背景

Breakpad的处理器旨在坐为核心的一种全面的崩溃报告系统，不需要调试信息提供给那些被监控的正在运行应用程序。一些现有的崩溃报告系统，如GNOME的Bug-Buddy和苹果的CrashReporter，需要符号信息出现在最终用户的电脑;对于CrashReporter，报告只传输苹果，不是第三方开发者。其他系统，比如微软的Windows错误报告和SupportSoft的反馈，只能传输一个崩溃的进程的状态快照，稍后可以结合符号调试信息，而不需要它出现在终端用户的计算机。因为符号调试信息消耗了大量的空间，软件正常操作时不需要的，因为一些开发人员都不愿意发布调试符号给客户，Breakpad遵循后一种方法。

我们知道目前没有崩溃报告系统,满足我们的要求：

• 允许符号独立于应用程序。
• 处理来自多个平台的崩溃报告。
• 允许开发人员操作自己的崩溃报告平台，并是开源的。

Windows错误报告只有对微软产品起作用,需要涉及微软的服务器。Talkback,是跨平台的但没有得到维护，此时不支持x86的Mac OS X(我们认为是一个重要的平台)。Talkback也是封闭源代码的商业软件，对服务器平台有非常具体的要求。

我们注意到,利用微软的调试接口仅适用于windows的崩溃报告系统。这样的系统,即使扩展到支持其他平台,转储与使用Windows作为一部分处理的平台。

概览

Breakpad的处理器本身是写在标准c++，将工作在不同的平台。它接收的dump可能也被不同的系统创建。此库能够把dump和符号的调试信息来创建堆栈跟踪，包括函数签名。处理器库包含简单的命令行工具来检查dump并处理它们，产生堆栈跟踪。这也暴露出几层api围绕着Breakpad处理器建立崩溃报告系统。

详细设计

dump文件

在处理器中,dump数据是首要的。dump文件通常包含：

• 这是在事故发生时的CPU上下文(寄存器的数据)，并指示哪些线程崩溃产生的原因。包括通用寄存器,专用寄存器如指令指针(程序计数器)。
• 每个线程执行崩溃过程的信息，包括：
  • 用于每个线程的堆栈的内存区域。
  • 由于崩溃线程导致多种原因使之不一致的每个线程的CPU上下文。
• 列表的加载代码段(或模块)，包括：
  • 有代码的文件的名称(so，exe，dll等)。 
  • 代码段是可见的进程的内存区域的边界。
  • 信息可用的代码模块的调试信息的引用。

通常情况下，dump产生的崩溃的结果，但是其他触发器可能被设置为在任何时间开发人员认为恰当时生成转储。Breakpad的处理器能处理转储在minidump格式，由Breakpad客户端”handler”实现(Breakpad client “handler”)，或由另一个产生转储在这种格式实现。这个平台上Breakpad处理程序实现是靠这个在Windows上产生dump的DbgHelp.dll的MiniDumpWriteDump函数。(DbgHelp.dll!MiniDumpWriteDump)

minidump format 本质上是一个一系列的流组织成的简单容器格式。每个流都包含某种类型的crash数据。一个典型的“正常”minidump包含流的线程列表，该CPUcrash时上下文，模块列表和各种各样额外的系统信息。minidump可以生成的其他类型，比如一个全内存minidump，除了有栈内存还包含此进程的所有映射的内存区域的快照。

这个minidump格式被选为Breakpad的转储格式,因为它有一个Windows上的确定的业绩记录，它可以适应满足Breakpad支持的其他平台的需要。其他大多数操作系统使用“core”文件作为他们的本地转储格式,但core文件的功能各不相同的平台，因为core文件通常代表了在一个平台的本机可执行格式，数据的访问不用头文件，定义一个可执行格式的整个结构。因为minidumps比典型的可执行格式简洁，重新定义格式在一个跨平台的头文件minidump_format.h，是一个简单的任务。同样，minidump格式的功能是被理解的，因为它提供了一个可扩展的容器，任何Breakpad不能直接由标准minidump格式满足的需要，可能会根据需要扩展它。最后,使用这种格式意味着至少在Windows上，转储文件兼容本地调试工具。未来探索可能的途径转换minidumps到core文件，使在其他平台上也能有这个相同的便利。

我们已经提供了一个扩展minidump格式，允许它携带PowerPC处理器产生的dump。多种cpu支持该格式，所以我们的工作在这个领域仅限于定义一个足以代表PowerPC执行状态的上下文结构。我们还定义了一个扩展，它允许minidumps表示哪些请求执行的线程dump是专为非崩溃dump。

通常,这些信息包含在一个dump本身是不足以产生一个完整的堆栈跟踪每个线程。某些优化编译器使用在生产代码阻挠这一过程。具体地说,“帧指针省略”x86编译器的优化，只有一个堆栈快照和CPU上下文，使它不可能产生有用的堆栈跟踪。在这些情况下,然而,编译器发出的调试信息可以帮助产生有用的堆栈跟踪。Breakpad的处理器能够利用这个微软提供的C/C++编译器的调试信息，唯一的编译器默认应用这样的优化。结论，Breakpad处理器可以产生有用的堆栈跟踪，甚至从被“帧指针省略”编译器优化过的代码。

符号文件

Breakpad处理器接受符号文件symbol files 允许帧指针省略数据，但这仅仅是他们的一个功能。每个符号文件还包含了关于这个函数，源文件和源代码行号为单个模块的代码。一个模块是一个individually-loadble代码truck：这些是可执行文件包含一个main的(exe文件在Windows)或共享库(在Linux上.so文件，在Mac OS X是.dylib文件、frameworks、bundlers，在Windows上是dll文件)。dump文件包含当产生dump时加载的模块信息，根据这种信息,Breakpad处理器试图通过一个用户提供的“符号供应商”模块功能来定位调试符号。Breakpad包含了一个symbol supplier示例，叫做SimpleSymbolSupplier，是命令行工具使用的；这个supplier文件路径定位符号文件。其他用户的Breakpad处理器库也可以用SimpleSymbolSupplier。这顾及简单引用的实现，但是保留了用户可能要求更高的存储需求符号文件的灵活性。

BrBreakpad的符号文件格式是基于文本的,被定义为人类可读的实现相当多平台的需求。Breakpad的处理器本身并不直接操作本地符号格式(在大部分类unix系统是DWARF和STABS，在Windows是pdb文件)，由于并发访问潜在的复杂符号格式与平台之间细微变化,存储在不同类型的二进制格式。对于pdb文件，调试格式甚至不是文档。相反，Breakpad的符号文件都由每个平台产生，可用时使用特定的调试api，将本地符号转换成Breakpad的跨平台格式。

处理

最常见的情况是,开发人员将通过构建它与一个特定于平台的客户端“handler”库client “handler” ，使一个应用程序使用Breakpad。在构建应用程序后，开发人员将使用dump_syms或symupload工具或另一个合适的工具创建符号文件，并将符号文件放在处理器的symbol supplier能够找到它们的地方。

当一个dump文件送给处理器的MinidumpProcessor类时，它将利用其包括包含在minidump类家族中的minidump reader读取它。它将收集关于操作系统和产生dump的CPU信息，确定dump是产生在崩溃时还是应用程序本身直接请求时。然后循环遍历进程中所有的线程，尝试游走堆栈相关联的每个线程。这个过程是通过处理器的Stackwalker组件，能处理dumps的每个CPU类型实现稍微不同。从一个线程的上下文,并可能使用调试数据,stackwalker产生一个栈帧表,包含每个指令执行的链。这些指令配合进程的模块，SymbolSupplier被调用来定位一个符号文件。符号文件被送给一个与一个特定的功能指令名称、源文件和行号相适应的SourceLineResolver，产生可以很容易地用于识别哪些代码被执行的堆栈框架。

处理的结果是产生在一个ProcessState对象，它包含一个线程的vector，每个都包含一个向量的堆栈帧。
minidump_stackwalk工具适用于小规模使用Breakpad处理器，测试和调试时。它调用处理器显示全部处理结果，用基于路径名的符号supplier(SimpleSymbolSupplier)可选地提供给处理器的符号。
对于较低级别的测试和调试，处理器库还包含一个minidump_dump工具，它游走整个minidump文件并以可读形式显示其内容。

平台支持

Breakpad处理器的库能够处理产生在使用x86、x86-64和PowerPC处理器的Mac OS X系统的dump，x86、x86-64处理器的Windows和Linux系统的dump，和ARM和x86处理器的Android系统的dump。处理器库本身是标准c++写的，在大部分类unix环境中正常运行。它已经在Linux和Mac OS X被测试了。

未来计划

公司目前没有计划或时间表来实现这些特性,虽然它们是可能未来探索的途径。

符号文件格式可以扩展以携带参数和本地变量存储在堆栈帧和寄存器信息的位置的信息，处理器可以使用此信息来提供增强的堆栈跟踪显示函数参数和变量值。

在Mac OS X和Linux上，我们可以提供工具将文件从minidump格式到本地core格式。这将使开发人员可以在一个本地调试器打开转储文件，就像在Windows上他们现在用minidumps能够做的。