调试符号文件（pdb）是一种很复杂的文件，由于这种文件格式微软并不公开，所以至今为止，并没有一篇文章或资料敢说自己对pdb文件进行了深入剖析。更重要的原因是，我们为了研究调试技术，需要知道一些系统（操作系统，编译器，连接器，调试器等）调试支持，仅仅知道即可，没必要深究微软为了实现调试而做出的每一个细节。
首先，我先问几个问题：

1. 我们经常用的调试方法，下断点，是如何实现的呢？
2. 我们可以在程序还没有执行起来的时候就可以下断点，等调试启动的时候，就可以命中这个断点。这个是怎么实现的？
3. 当断点命中时，我们可以观察一个变量的值，这是怎么实现的？

先简单讲解本文中用到的两个概念：

1. OFFSET，文件中的偏移。
2. VA，程序加载到内存后的一个虚拟地址。

假设在一个EXE文件中，有一个全局变量a，距离文件起始的偏移为0x10，此时文件的起始位置为0x00000000，那么该全局变量a的OFFSET就是0x00000010。当这个exe执行起来，加载到内存后，这个exe本身所加载到的内存位置称为基地址。假设基地址为0x00400000，那么这个全局变量a的VA便是0x00400010。可见，exe本身所加载到的基地址不一样的话，那么a的VA就不能确定。
依然使用最简单的例子，来阐述原理，代码如下：

可以观察到，此时，笔者并未调试启动程序，而这个断点，就已经打上了。接下来我们调试启动程序，如下图：

此时，我们已经进入断点，并中断下来，我们可以观察到全局变量g_nVar的值。想必这个过程，有过VC++开发经验的开发者，再熟悉不过了。下面，详细分析一下这个过程。
当我们鼠标点击下断点的时候，我们的程序还没有启动，VS是不可能知道这个断点应该打在内存中的哪一条指令的地址处的（此时，VS顶多知道断点所在的OFFSET，但是无法知道断点所在的VA），但是VS可以记录到一条重要的信息，就是当前断点在哪个源文件的哪个行号上。
接下来，我们调试启动程序，exe的镜像加载到内存后，所有代码段的指令的VA便是真实可用的了。但此时调试器是如何根据断点所在源文件和行号，来找到断点所在的VA的呢？现在，你应该想到本文在讲什么，哈哈，就是pdb啦。那么pdb文件中到底存了什么，才让调试器可以根据源文件及行号来找到对应的VA呢？

默认情况下，在pdb文件中，保存了可执行文件中所有的符号（函数名、变量名等）所在源文件、行号、OFFSET等信息。但是这些信息，是在什么时间得到的呢？很明显是编译阶段，编译器在编译每个cpp的过程中，就可以把这些符号的相关信息收集起来，存放在各个cpp所生成的obj文件中，然后在链接的时候，提取每个obj中的这些信息，生成一个单独的pdb文件。这样，以后调试程序的时候，调试器只要找得到这个pdb，就可以知道可执行文件中，所有符号所在的源文件、行号和OFFSET了。反过来说，当给出一个源文件和行号，就可以拿到对应的OFFSET了，所以在还没有启动调试的时候，我们下的断点，实际上调试器是知道这个断点应该在哪个OFFSET上了，等启动调试的时候，用这个OFFSET加上这个模块所加载到的基地址值，就可以得到这个断点所在的VA了，然后在这个VA处强行写上int
3指令，并继续执行，当执行到这里，便中断下来给我们一个调试机会了。想想，如果没有pdb，这个断点还能用么？
当我们鼠标放在某个变量上时，调试器可以拿到这个变量的名称，根据我们前面说的，用这个名称去pdb中查找，自然就可以找到pdb文件中保存的OFFSET了，加上这个模块的基地址，就找到了这个变量所在内存的VA，剩下的就是读一下这个VA内存中的内容了。这样也就实现了观察变量值得功能。
下面证实一下，pdb文件中确实存储了源文件、行号、OFFSET等信息。将上面例子代码放到VC6中编译，然后到debug目录中使用dumpbin来查看CodeTest.obj文件中的符号信息，如图：

可见，add函数和main函数所在行号和起始行号和结束行号都是有记录的，那源文件是哪个呢？哈哈，当然是CodeTest.cpp了，我们查看的是CodeTest.obj文件嘛。。。
但是这里并没有add或者main函数的OFFSET啊，为什么呢？想想，此时只有一堆obj，真正的可执行模块还没有生成出来呢，何来的可执行模块的OFFSET呢。。。由此可以知道，这个OFFSET要在链接过程中，才可以确定。经过了链接之后，这些本来在obj里的调试信息，也就被收集到pdb文件中了，下面我们来找找add函数的OFFSET到底在哪里？使用SymView工具打开CodeTest.pdb文件，如下图：

可见，pdb中存储了add函数相关信息，不仅仅只有offset，而且此处并未直接记载add函数在哪个cpp里，这些关系都是通过索引来查找的，其实pdb文件的内部结构是很复杂的，要想解释清楚，其实很不容易，大家如果想知道pdb内部到底都有什么东西，可以参考一下《软件调试》第25章，但也是讲了个大概。

在我们观察的过程中，我们可以发现两个很主要的特征：

1. 可执行模块中，保存了当前模块的调试符号文件的路径，而且是绝对路径，如下图：
   
2. Pdb文件中保存了每个cpp文件的路径，而且也是用的绝对路径。如下图：
   

 这样，我们可以得出一个结论：

1. 在同一台开发者的机器上，如果被调试的exe放在了其他目录里，而pdb依然在原来生成时所在的位置，那么调试exe时，依然可以找到对应的pdb文件。
2. 如果exe和pdb都换了路径，只要调试的时候，我们手动指定了pdb所在的位置，如果源码文件还在原来的路径，那么调试时，依然可以找得到源码文件。

Diomidis Spinellis是《代码阅读与代码质量》一书的作者。在GOTO阿姆斯特丹2016大会上，他就如何有效地调试软件和预防错误做了演讲。InfoQ采访了Spinellis，内容涉及发现和修复软件中的错误、软件调试的原则、如何提高调试效率、如何编写出不怎么需要调试的代码以及管理人员如何为错误预防和处理提供支持。

InfoQ：是什么让软件错误的发现和修复如此困难？

Diomidis Spinellis：如果你认为编写代码困难，那就尝试下代码调试吧。你编写了一个新的函数或方法，并加上一些语句形成某个只是貌似正确的东西。当你调试一个程序的时候，你要面对数千或数百万行貌似正确的代码，并设法找出其中的错误。这必定要困难许多。然后，你还要应对各种系统和层次之间的复杂交互、每秒执行数十亿次的CPU指令、难以再现的Bug以及来自生产环境系统的压力。

而且，课堂上很少教调试；从一切可能出错的东西辛苦得来的经验很难压缩到一次演讲中。此外，由于系统失败的方式各不相同，你必须不断地改进和调整你所用的工具和方法。你可以从观察开始，继之以数据分析，然后做一些试验，最后推断出Bug的原因。没有什么标准的初学者技能。

InfoQ：软件调试有什么一般原则吗？

Spinellis：很遗憾，由于软件会出现各种难以想象的错误情况，我不认为有什么可以在软件调试过程中遵循的一般原则。退而求其次，我归纳出了三大类方法：

高级策略，比如由故障特征推断出原因，或者确保某些代码满足了其前提条件；

方法和实践，比如确保Bug可以有效地再现，或者着重突出故障的影响；

通用工具，比如Unix命令行工具、跟踪（考虑下strace、dtrace和systemtap）工具和版本控制系统。

InfoQ：程序员做什么能够提高调试效率？

Spinellis：首先要为调试成功做好准备。让自己相信问题将会得到解决，留出足够的时间用于调试，不要分心，要坚持不懈，必要的时候，留待第二天解决。重要的是，要不断地在环境、工具和知识上投入。购买高效工作所需的软件和硬件。例如，如果软件生成大量的调试日志文件，你就应该有足够的磁盘空间、CPU处理能力和带宽，以便可以高效地处理它们。在调试的过程中，你很容易遇到千奇百怪的问题，因此，花些精力管理和优化自己的环境和工具配置。这包括按键绑定、别名、辅助脚本、快捷方式和工具配置；所有这些都可以显著地提高调试生产力。

InfoQ：有什么技术或方法可以编写出不怎么需要调试的代码吗？

Spinellis：当然！编写可维护的代码——可读、稳定、易于分析和修改的代码——带来的Bug也比较少。此外，像单元测试、代码审查这样的方法以及使用断言都有助于最小化进入生产环境的错误。

在设计时使用高级抽象（例如使用一个框架的算法或容器数据结构，而不是选择自己开发一种方案）可以减少代码和错误。另外，让程序易于调试也很重要。这包括为详细地记录日志提供便利，当出现内部错误时报告丰富的上下文信息，并将问题及崩溃的详细信息发送到一个中央存储库。

InfoQ：管理人员如何为组织里的错误预防和处理提供支持？

Spinellis：设定基本的过程有助于确保软件错误不会失控。部署并采用一个问题跟踪系统，用它把要处理的问题分类并排定优先级。将软件变更恰当地记录在进一个运作良好的版本管理系统里，并将它与问题跟踪系统联系起来；我经常仅仅通过仔细研究一个文件的历史和变更就修复了Bug。在软件建设方面，推广单元测试的应用，把软件的构建性能分析、静态分析和动态分析包含进来，并维护一个快速、精益、均衡的构建-测试周期。这有助于帮助开发人员尽早捕获Bug，并迅速修复。最后，在运维方面，逐步部署软件，允许新旧版本对比，努力确保所使用的工具和所部署的环境的多样性，并有组织地升级工具和库。

转自：http://lf.lnu.edu.cn/detail.jsp?id=55243

在硬 件可靠性 理 论 中 , 典 型 的失效 率 又( t ) 函 数是 一条 形 似“ 浴 盆” 的曲线 。 浴 盆 曲线 由三 段 构成 : 早 期故 障期 、 偶 然故 障期 、 耗损 故 障期 。 这种 曲线描 述 了事物 生命期 的 整个过 程 , 而 且具 有普遍 性 。 对 软件来 说 , 在调 试排错 阶 段 , 故 障易 被发现 , 也 易于 纠正 , 而且 在纠 正 中引 人新 故 障的概率 较小 , 因此 , 在 此 阶段 , 软件 失效率 是递 减 的 ; 当软件 中存在 的残 留错误 数减 少 到一 定数 目后 , 由于 故 障发 现率 较 低 , 故 障机 理 较复 杂 , 再 发现 的错 误 一 般就 难 以 得 到 纠 正 , 甚至 在纠正 过 程 中又 引人新 的错误 , 从 而使 得 软件 在运 行 阶 段失 效 率基 本保 持 不变 ; 在 软件 生存 的后期 , 由于 软件 应用 范 围 的扩 大 , 或 用 户对 软件 功 能 提 出更 新 的要求 , 从 而 导致 软件故 障增多 , 而 对其 纠 正越来 越 困 难 , 很 易引入新故 障 , 这样 使 得软件 失效 率呈 递增趋 势 , 直到软件寿命 期结 束 。 因 此 , 人 们把 浴盆 曲线 理论运 用到 软件 可 靠性领 域来 , 结合 软件 固 有 特性 , 提 出了许 多评 估软 件 可 靠性 的模 型 , 并 在实 践 中 得到 了广 泛 应用 , 取 得 了 良好 效 果 。
J一M 模型 就是 其 中 的一 种 , 它对 应 于浴 盆 曲 线 的第一 段 , 适 用 于软 件 调 试排 错 阶 段 , 这类 模 型 统称 为软件 出生 模型 ( Born-In模型)。

1、J一 M 模型简介

J 一M 模型 是 由 2 . Je lin s ki 和 P . B . M o r a n d a 于 19 7 2 年提 出的一种 确定 性模 型 , 简 称 J一 M 模型 , 用来描述 软件 错误 的检 测过 程 。 根据软件 特性 , 在 B o r n 一 n I 模 型 中规 定 了 四 条基本 假设 ：

• 假 设 1 : 错误 纠正 时 间忽略 不计 ;
• 假 设 2 : 纠正 所发 现 的错误 不会 引人新 的错误 ;
• 假 设 3 : 两次 失效 时 间间隔相 互独 立 ;
• 假设 4 : 两次 失效 之间 的失效 率是 与时 间 t 无 关的 常数 。

J一M 模 型 除 上述 四 条基 本假 设外 , 还增 加两 条假设 ：

• 假 设 5 : 软件 失效 率与 当前 的软 件 残 留错 误数 成正 比 ;
• 假 设 6 : 所有 残 留错 误 的错 误尺 寸 视为相 同 。 所 谓错误 尺寸 , 是指 因某 一软 件错误而 导致该 软 件失 效 的概 率 。

由上 述假设 可 得到 J一M 模 型 的失 效率 曲线 如 图  所示 ：

失 效率 和 可靠 度 函 数 可 表示 为 ：

式 中 , N 表 示 开始 时 软 件 存 在 的 错 误 总 数 ; ∮表 示错 误 尺 寸 , 由假设 6 知∮是 个 常数 ; λ表示第( i一 1 ) 次 失 效 至 第 i 次 失 效 为止 , 这 段时 间 的失效 率 ; R_i ( t )表 示第( i 一 l ) 次失 效 至第 i 次失 效 为止 , 这段 时 间的软 件可靠性 函 数 。
式 中的 N 、 ∮必两参 数可 由极 大 似然法 估计 出来 。 如果 以 X _i ( i=1 , 2 , … , n ) 表示被 观察 到 的一 系 列失 效 间 隔时 间 , 则 可 求 得第 n 次失 效后 的软件 可 靠性 函 数 估 计 , 以 及到 第 n + 1 次 失效 发生 的平均 间隔 时间 的估 计 。

2、 J一 M 模型分 析

J一M 模 型 的准确性 主要 取 决于 假设 的有效 性 。 在 软件 的调试排 错 阶段 , B o r n 一玩 模 型 的 四 个基 本假 设 是 比 较 合理 的 , 而 对于 J一M 模 型 所 附 加 的 两条 假设 , 在 软 件 工 程实 践 中具 有 一 定的缺 陷 。 首先 , 软件 的失效 率不 仅仅 取决 于 当前残 留错 误数 。 例如 , 一个 仅含 有 两个不 常碰到 的 错 误 ( 即错 误 尺 寸非 常小 , 如 0 5 死锁 等 ) 的 软件 5 1 , 另 一个 仅 含有 一个 经 常 出现 的错 误 ( 即 错误尺 寸较大 , 如 下标动 态超 界等 ) 的软件 5 2 。 显而 易见 S , 比 S : 可靠性 高 。 这样 , 假 设 5 就 不 成 立 。 其次 , 根 据 定义 , 错 误尺 寸是 某一 错误 导致 软件 失效 的概率 , 即对 软件 失效 率 的贡 献率 。 很 明显 , 错误 尺 寸越大 , 就越 容易 造成 软件 运行 失效 , 就越 容易被 发现 ; 反 之 , 错 误尺 寸越小 , 就越难 被发现 。 从 另一 角度说 , 越 先 发现 的错误 , 其错 误尺 寸越大 ; 而越 是 后发 现的错 误 , 其 错 误尺 寸越小 。 也 就是说 , 不 同的 软件 错误 , 其错 误尺 寸是 不相等 的 , 而是 随着被 发现 的顺 序 呈 递减 序列 。 这样 , 假设 6 也 不成 立 。 综 上 所述 , J一 M 模型 所 附加 的 两 条 假 设 , 对于 某 些 软 件 工程不 适 用 , 不 能很 好地 反映 软 件 的客观状 况 。 此外 , 适 用于 软 件 调试 阶段 的其它 出生模 型 , 如 B a y e S 模 型 、 Sh o o m a n 模 型 、 非 出错计数 模 型 等 , 也都存 在 类似 的 问题 , 为此 , 应 予改 进 。

3、新的评估模型

软件 的失效 率不 仅与其 残 留错误 数 有关 , 而 且与每 个错 误 的错 误尺 寸有 关 。 如 果软件 残设 : 开始 时软件 的残 留错误 数 为 N , 其 相 应 的错 误尺 寸 为 ∮_j( j= 1, 2 , … , N ) , 则 失 效 率与可靠性 函 数 由下 式表 示 :

由于 错误 尺 寸随 着发现 的先后 次 序呈 递减 序列 , 因此 : ∮_j>∮_j+1; 。 如果 直接 用 ( 2 ) 式 进行分 析计算 , 比较 困难 。 为减化计算 , 根据 ( 3 ) 式 引人假 设 7;

假设 7 : 第 i ( + l ) 个 错 误 与 第 i 个 错 误 的 错 误 尺 寸 之 比 为 常 数 。 即 : ∮_j+1=K*∮j( 0 < K < 1 )。
令 笋 ∮j=∮1 ,则，∮_j=k^j-1* ∮这样 ( 2 ) 式变 为 :

4、软件故障数据 的收集与预处理

软件 测试 数据 是 软件 可靠性 评估 的基础 , 在软 件调 试排错 阶段 , 开 发人 员应详细记 录每 次 软件故 障 间隔 时间 , 保证 数据 的客 观性 和 准确性 。 对 收集 的数据 在用 于评估 前 , 应进 行初 步处 理 。 对重 复 出现 的故 障 , 应将 前 几 次故 障数据 剔除 , 保 留最后一 次真 正 消除软 件故 障的 那个数 据 , 即如 果第 i 次 出现 的故 障剔 除 不成 功 , 应将 x ` 删 除 , 同时 将 x 、 ,数 据 赋 予 x 、 , 即 : x 、 一` + , 一 t、 , 以 此 类 推 。 另外 , 如果 有 多个 程 序模 块 , 则 各模 块 的故 障数 据应 分别 记 录 , 不 要 混 淆 , 同一程 序模 块 的不 同版本 的软 件故 障数 据也 不要混 淆 。 收集到 一定 数量 的数 据后 , 就 可 以 进行 数据 分析 , 代 入评估模型 进 行评估 。
5 结束语
过 去 由于缺 少切 合 软件 开发 实际 的 软件 可靠 性评估 模 型 , 在 系统 工程 产 品 的可 靠性 分 析 和评估 中 , 只 对 硬件进 行 , 而将软 件 可靠 度视 为 1 , 即不 考虑软件 可靠 性 问题 。 事 实上 随着 硬件 可靠性 的不断 提高 , 软件 可靠性 显 得 日益突 出 。 而 且一 个软件 模块 , 开发 人员 调试到 什 么 程 度就 可结 束调 试排错 , 也 就是 如何 确定 软件 调试周 期也 是个 棘手 的问题 。 本文 正是基 于 这 种 情况 , 结 合 系统 工程 实 际 , 对 软件 调试 排错 阶段 的可 靠性 评估 模 型 进 行探 索 , 使 得软 件 开发 人员在 软件 调试 阶段 收集 n 个 数据 后 , 经 过 预处理 , 运 用本 文提供 的评估 模型 计算得 到 该 软件 残 留错 误总数 及下 一个 软件故 障出现 的平 均时 间 。 排除第 n 个软 件错 误后 , 也可 以估 计 出该软件 的平 均无 故障 时 间及 排 除剩 余软件 错 误还需 工作 的时 间 。 这 对于 开展 软件可 靠 性 增 长试验 , 合理 确定 调试 周期 , 调整 软件 开发 计划等有 较大 作用 。

弗雷德里克·布鲁克斯( F r e d e r i c k P·B r o o ks ) 博士在他那篇著名的《没 有 银弹— 软件工程 中的根本和次要问 题》 一文 中 , 将软件项目比作可怕的人狼 (w e r e w o l v e s ) , 并大胆地预言十年内不会 找到特别有效 的银 弹 。 该论文发表的时 间是 19 8 6 年 , 如今整整 2 0 年过去了 , 尽 管不时有人惊呼找到 了神奇的银弹 , 但是 冷静的人们很快发现那只是美好的愿望 。
如果说 软件工业 中与人狼 的战 斗还在持续 , 那么在这些战役 中一 定会有程 序 员的身影 , 笔者 也是 其中的一个。 我的 编程生涯是从使用汇编语言编写 D O S 下 的 T SR 程序开始的。 今天 D O S 操作 系统 已经成为历史 , 在那个年代最值得炫 耀 的 T S R 技术也早 已经过时了 。 十几年 中 ,O W L、V F W、V D X、ISA P I、A e ti v e M o v i e 等技术也被 时间淘汰… …然而 , 在这漫 长的时间当中 , 我最看重的是软件调试技术。它是十几年中我学到的最有用、一直受用、而且 日久弥新的一项技术。
从软件 工程 的角度来讲 , 软件调试 是软件 工程 的一个重要部分 , 软件调试 过程 出现在软 件工程的各个阶段 。 从最初的可行性分析、原型验证、到开发和测试阶段、再到发布后的维护与支持，都有调试过程的参与。通常认为，一个完整的软件调试过程由以下几个步骤组成：

• 重现故障
  通常是用于调试的系统上重复导致故障的步骤，使要解决的问题出现在被调试的系统中。
• 定位根源
  及综合利用各种调试工具，使用各种调试手段寻找导致软件故障的根源 (o r o t c a u s e )。通常测试人员 报告和描述的是软件界面或工作 行为中所表现出的异常 , 或者是 与软件需求 和 功能 规约不 符 的地方 , 泛 指软 件 缺 欠(d e f e c t ) 或者故障 (f a i l u e r )。 而这些表面 的缺欠总是 由于一或 多个内在 因素所 导 致的 。 这些内因要 么是代码的行为错误 , 要么是不行为错误 (该作而未作 )。
•  探索和 实现解决方案
  即根据寻 找到的故障根源 、 和资源情况 、 紧迫程度 等要求设计和实现解决方案。
• 验证方案 ,
  在 目标环境中测试方 案的有效性 , 又称 为回 归 (e r g e r s s ) 测试。 如果 问题 已 经解决 , 那么 就可以关闭问题。 如果没有解决则回到第 3 步调 整和修 改解决方案 。

这些步骤 中 , 定位根 源常常是最困 难也是 最关键的步骤 , 它是软件调试过 程 的核心 和灵魂 。 如果没有找到故障根源 , 那 么解决方案便很是隔靴搔痒 , 或者 头痛医脚 , 白白浪费了时 间。 对软件调试的另一种更通俗的解释是指使 用调试工具求解各种软件 问题的 过程, 例如跟踪软件的执行过程, 探索软件本身或者与其配套 的其它软件或者硬件 系统的工作原理等 , 这些过程 的 目的有可 能是为了去除软 件缺欠, 也 可能不是 。

在了解了软件调试技术的基本概念 以后 , 下面我们来看一 下支撑软件调试 技术的几种基本机制 。

• 断点 : 即当被调试程序执行到某一 空 间或时间点时将其中断 到调试器 中。 根据中断条件分为如下几种 :
  a、代码断点: 当程序执行到指定 内存 地址的代码时中断到调试器 。
  b、数据断点 : 当程序访问指定内存地 址的数据时中断到调试器 。
  c、I/O 断点: 当程序访 问指定 1 / 0 地址 的端口 时中断到调试器 。
  根据断点的设置方法 , 断点又分为软 件断 点和硬件断点。 软 件断点通常是通过 向指定的代码位置插入专用的断点指令来实现的 . 比如 IA 32 C p U 的 IN 丁 3指令 (机器码 为o x C C ) 就是断点指令。 硬件断 点通常是通过 设置 C PU 的调试寄存器来 设置的。 IA 3 2 C PU 定义了 8 个调试寄存 器 , D R O一 D R 7 , 可以最多同时设置 4 个硬 件断点〔对于一 个调试会话)。 通过调试寄 存器可以设置以上三种断点中的任一种, 但是通过断点指令只可以设置代码断点。
• 单步跟踪 : 即让应用程序按照某单 位一步步执行。 根据单位 , 又 分几种:
  a、每次执行一 条汇编指令 , 称为汇 编语言一级的单步跟踪。 设置 IA 32 C Pu 标志寄存器的 T F (rT 叩 lF a g , 即陷阱标 志位 ) 位 , 便可以让 C P U 每执行完一条 指令便产生一 个调试异常 (N I T I ) , 中断 到调试器 。
  b、每次执行源代码 (比汇编语 言更 高级的程序语言, 如 C / C料 ) 的一条语句 , 又称为源代码级的单步跟踪 。 通常高级 语言的单步跟踪是通过反复设置 C P U 的 陷阱标志位来实现的, 如果 当前源代码行还没有执行完 , 那么调试器重新设置 陷阱 标志并让程序继续执行, 直到该语句结 束(E I P 指向另一语句 ) 才中断给用 户 。
  c、每次执行一个程序分支 , 又称 为 分支到分支单步跟踪。 设置 IA 32 c Pu 的o bg e t lM s R寄存器的 B T F (B ra n e h T ra pF l g a )标志后 , 便可以启用分支到分支单 步跟踪 。
  d、每次执行一 个任务 (线程) , 即当 一个任务 (线程 ) 被调度执行时中断到调 试器 。 IA 3 2 架构所 定义 的任 务状态段( T Ss ) 中的 T标志为实现这一功能提供 了 硬件一级的 支持 , 但 是很多调试器还 有 提供这项功 能。
• 栈 回溯 (s ta e k ba e k ta r e e ) : 即通过记 录在栈中的 函数返 回地址显示 (追溯 ) 函 数调用过程 。 在将返 回 地址翻译 成函数 名时需要有调试符号 ( de b u g sy n t b o l ) 的 支持 。 大 多数编译 器都支持 在编译时生 成调试符号 。 微软的调 试符号服 务 器
  ( h t t P: // m s d lm ie r o s o f te o m /d o w n lo a d /sy n t b o ls )提供 了大 多数Wi n d o w s 系统文件 的调试符号 , 是调试和学习w id n o w s操作 系统的宝贵资源。
• 调试信息输出(de b铭 o u tP u印i r n t ) : 即将程序运行 的位置 、 变量状态等信 息 输出到调试器 、 窗 口 、 文件或者其它可以 观察到的地方 。 这种方法的优点是 简单方便、不依赖于调试器 , 但也有明显的缺点 , 如效率低 , 安全性差 , 通常不可以动 态开启 , 且难以管理等 。 在W i n d o w s 操作 系统中 , 驱动程序可以 使用 D b g r P in t /D b g P i r in E x 来输出调试信息 , 应用程序可 以调用o u tP u tD e b u g s i t r n g API
•  日志 ( 1 0 9 ) : 将程序运 行的状态信 息写人到特定的文件或者数据库中。 W in d o w s 操作 系统提供 了记录、观察和管理 (删除和备份 ) 日志的功能 。 Win do w s v is a t 新引入 T 名 为 C o m m o n L o g F i le s y s t e m (c L s F . S Y s ) 的内核模块 , 用于进一步加 强 日志功能 。 .
• 事件迫踪 (e v e n t t r a e e ) : 通 常用来 监视频 繁的复杂的软件过程 , 满足普通 日志机制难以胜任 的需求 。 比如监视大 信息t 的文件操作、 网络通信等。 E T W ( E v e n t T r a c e f o r Wi n d o w s ) 是Wid n o w s 操 作系统内建的事件追踪机制 , Wi n d o w s 内 核本身和很多W in do w s下的软件工具(如 B o v o t i s , T C即 P V ie w )都使用了该机制 。

在以 上机制中 , 断 点和单步跟踪通常必须在有调试 器参与的情况下才能使 用 。 调试器 ( s o f t w a e r de b u g g e r ) 是综合提 供 各种调试功能的软 件工具 。 除了处理断点、单步跟踪、模块映射等调试事件外 , 调试器通常还提供如下功能 :

• 观察和编辑被调试程 序的内存和数据 , 如全局变量、局部变量、以及程序的栈和堆等重要数据结构 。
• 观察和 反 汇编被调试程序的代码。 
• 显示线程栈 中的函数调 用信息 。
• 管理调试符号 。
• 控制进程和线 程 , 例如将 被调试 程序中断到调试器中 , 和恢 复其执行 等。

根据调试器 所调 试目标程序的工作模式 , 可 以把调试器分 为用户态调试器 和内核态调试器 , 前者用于调试用户态下的各种程序 (应 用程序、系统服务 、 或者用户态的 D L L 模块 ) , 后者用于调试工 作在内核模式 的程序 , 如驱动程 序和操 作系统的内核 部分 。 Wi n D b g 是微软开 发 的一个免 费调试器 , 它既可以用 作用户 态调试器 , 也可以用作 内核态调试器 , 是调试 Win d o w s 操作系统下的各种软件的 一 个强 有力工 具 。 我 几乎 每天都使 用 w in D bg , 它是我 的计算机 中使用频率最 高的软件之一。

最后 , 简要地描述一下软件调试技 术的几个特征。

系统性— 很多看似简单的调试机制 都是依靠系统 内的 多个部件协 同工作 而完 成的 。 以软件断点为例 , C P U 提供了 指令支持和硬 件级的异常机制 , 操 作系统将异常以调试事件的形式分发 给调试 器 , 调试器响应调试事件并与用户交互。 如果在做源 代码级的调试 , 那 么调试 器 又需要编译器所产生的调试符号来帮忙 。

全局性— 对于一 个软件项 目 , 应该 在项 目的设计 和架构阶段就制 定出全 局的调试支持机制 , 并贯彻实施。 比如 , 所有模块都应 该使用统一的 方法 来输出调试信息、记录 日志 、 报告错误 , 并公开 统一的 接 口 用做单元测 试和 故障诊 断 。 这样不仅可以避免重复工作 , 而且增加T 软件的 可调适性 (d e bu g g a bi一 i ty ) , 有利 于保证产品的质量和进度。

困难性— 《C 语言编程》 一书的作者 B r ia n K e r n ig ha n 曾经说过 , “ 调试天生就 比编写代码难上一倍 , 如果你 写出 了最聪明的代码 , 那 么你的智商就不足以 调试这个代码。 ” 因为 , 要调试一个程序 ,就必 须深刻理解它的 工 作原理 , 不仅要知道 h o w 和表 层的东西 , 还要知道w h y 和 深层次的 内幕。 另外 , 调试需要锲而不 舍的探索精神和坚韧的耐 力 , 这 也让很 多 人望而却步 。

综上所述 , 软件调试技术是与软 件 开发 密不可分的一门技 术 , 其初衷是 为了定位和 去除软件故障 , 但 因 为调试技术所具有 的对软件的 强大控制 力和观察 力 , 其应 用早已 延伸到 了很 多其它领域 , 比如逆向 工程 、 计算机安 全等等。 学习和 灵活运用软件 调试技术 , 不仅可以提 高程序 员的 工作效率 , 而且有 利于提升 对代码的感 知力和控制 力 , 加 深对软件和系统的理解。 此 外 , 调试技术 是解决各 种软件 难题 的一 种有效 武器 。 它直击要害 、 锐不可档 , 相对其 它间接方 法具有明显的优势 。 软件有大美 , 调试 见真功。 在寻找银 弹的 努力还 在继续的时候 , 衷心地 希望所有程序员朋友都学 会使 用调试这把利 剑吧 , 使用它为你披荆斩棘 , 帮你探索前进。 只要你的这把剑依然 锋利 , 那你的软 件青春就永远不老 。

随着计算机技术的飞速 发展和普及 , 越来越多的人直接与计算机打交道 , 因而产生 了研 究计算机操作者心理状态 的一 门综合性很强的边缘交叉科学 - 一软件心 理学。 软件心 理学 把实验心 理学 的技术和 认知心理学的概念应用于 计算机和信息科学 , 它 主要研究了计算机 科学 中人机系统和软件设计中人类心 理和 行为活 动的规律。 对软件心理 学的研究 , 在我 国还 是刚刚起步 , 本文对这一领域进 行了探讨和尝试 , 探讨 程序调试过程中人机对话对人的心 理 的影响 , 探讨了人同机器会话的心理 感受 , 探讨程序与 机器速度 的关系 , U N IX 分时系统终端数与模块大小的关系。 进而探讨如 何确定合适的程序模块, 合理的选择机型 , 使程序员不致因为环 境因素造成软件调试过程中的心理 压力 。

心理承受能力实验

首先把用户 (程序员 ) 对机器响应的承 受能力分成七个等级 : 极快 (1 ), 快 (2 ), 较快 (3） ,中等 (4 ) , 稍慢 (5 ), 慢 (6 ), 无 法忍受 (7) 。 本文 主要讨论如下几个问 题:

• PC 机及兼容机 上编译 C 语言程序时的心理 承受能力分析;
• U N IX 分时操作系 统环 境下 , 编译 O 程序的 过程 中如何影响程序员的心理 状态 ;
• 人机会话期间 , 中间信息的输入/ 输 出对程序员的影响。
• P C 机编译 C 程序的实验 选择 P C /X T 和 C 8 6 2 . 0 编译器 , 把给定的 6 0 个大小不 等的程序共

P C 机编译 C 程序的实验

选择 P C /X T 和 C 8 6 2 . 0 编译器 , 把给定的 6 0 个大小不 等的程序共分成 6 组 , 侮组 」 0 个程序 , 分组 原则是第一组 语 句 2 1 ~ 3 0 行 , 第二 组 3 1 ~ 4 0 , 第 三组 4 J ~ o 6 , 第四组 6 1 ~ 阳 , 第五组 8 1” 1 0 0 , 第六组 10 0 ~ 20 0 。 对每组程序进行编译测试 , 得出的时间求平均位 , 对该 组程序的承受级别求平均值。 以第四组 程序为 例说明测试 的过程和测试结果 : 参加测试的四名程序员是计算机软件专业 本科 四年级的学生。 A , B 男同学 , O , D 女 同学。 测试 过程如下: 先 给 10 个程序编号 P 丸 P Z , … , P I O。 A , O 一 组 , B , D 为 另一 组。 以A、C 组 为例 。 C 开始编译 一个程序 iP , 记录 下开 始 时间 T l 和结束时间 T Z , 当程 序 曰 编 译 结 束时 , A 说出感 受级 别, 记录下 编译时间 口、2一甲1 、 , 0 J 个 程 序都测试一 遍 。 人 . e 角 色 互换再 测试 一 遍 , 得出 O 的承受级别 , 同样测 出 B , D 的 承 受级 别

平均编译时间 2 6.89 秒 , 平均承受级别3 . 8 ( 中等)。 其中二名男同学的平均承 受 级 别4.0 , 二名女同学 3 . 6 。 同样的方法 得 出 6 组程序平均编译时间 、 平 均承受级别如 表1.

 顺便说一下 , 每组程序测试的结果都表明, 女同学的承受级别普遍小于男同学10% 左右 , 这 点说明了在调 试过程中, 女同学更有忍耐性 , 更适合做调试工作 (而不是设计)。

不 同机型编译 C 程序

选择第六组程序进行实验 (实验过程类似上面实验 1 )。

有屏幕输出信 息的 心理测试实验

对 于小程序 , 看屏幕输出与不看屏幕输出对程序员心理 无 明显影响 , 对于 第六 组 稍大一 点的程序 , 看屏幕输出时, 在 S U P E R P O/ X T 机上, 平均编译时间仍为 38 . 2 9 秒 , 但用户平 均感受级 别 4 , 在 P O /X T 2 8 6上 , 平均感受级别仍是 3 。 这一结果指 出了 中间信息的输出 有 时对改善程序员心理有较大作用 , 有时则不 明显。
UN I X 分 时系统编译 实验 ( 680 00 机 )

进行 680 0 0 机编译实验时 , 增补一 些较短的程序 , 被测程序语句行 1 0 ~ 2 0 0, 实验结果如下 :

4 台终端同时工作 , 每个程序编译时间4 0 ~ 62 秒 ;

6 台终端同时工作 , 每个程序编译 时间7 0 ~ 11 0 秒;

9 台终端同时工作 , 最短程序编译时间接近 3 分钟。

从中看 出, 分时系统进行编译或运行 , 对用户心理 压力最大的因素来 自同时工 作终端数 ( C P U 速度) , 其次才是程序规模。 因此 , 安排 学生 在分时系统上 机时 , 应考虑这点。

程序调 试中个体差 异 的实验

本实验是让二名受试者背对机器 , 编译开 始时 , 二名受试者被告之 开始 (事实上 , 根本就 没有编译程序 , 只是发出指令信号 ) , 被测者根据自己感觉的时间 , 说出心理 感受级别, 下 面 是记了结果

实验分析与结论

这 里讨论的一 些结论全 部基 于心理承 受级别不能超过 4 ( 中等) , 承受级别 5 ~ 7 时 , 对 程序员的程序调试有很大的心理 和身 体影响。 长期的心理 压力也影响程序调 试 的 准 确 性 , 增加出错率 , 导致程序调 试的逆反心 理。
1、机器速度对程 序员心理 的影响 表 1 中数据表明大于 8 1 行语句的程序在 S U P E R P O / X T 上编译时, 承受级 别 5 , 而在 邹 6 _ ! 几编 译至少 级别是 3 。 这说 明了大于 8 1 一 行的程序模块至少 要在 2 86 上调 试 。 P C 机 及 卫C / x T 的低档机只 可 做简易 的实习用。
2、屏幕输出对程 序 员心理 的影响 实验 3 的结论指 示 了增加屏幕输出有助于 改善调试 程序的心 理压 力 , 但 太 多 的 增 加 I / O 信息又 延长编译时间 , 是否 有数据可 参考呢 ? 实验 3 数据表明 3 8~ 4 0 秒的 界 限是心理 危机的开始, 因而编译程序应在运行 3 8 秒左右时提供一 些 信息。 如 p O T O O I J 一工具进行磁 盘O O p Y 时 , 有磁道的一些信息输 出。 用户 自身的程序运行时, 3 8 秒同样是个界值 , 用户 应 在相应的程序处加上 1 / 0 信息 , 由于机器主频不一致 , 用户 自己根据情 况处理 。 爪 l ) J E R 卫o / x T 一般 10 0 ~ 20 0 语句 , 2 8 6 一般 ` 1 0 0~ 加 0 等 , 这只是笔者之 建议 , 供参考 。

3、速度祖的机器 运行大程 序心 理调整 由于 P O 及 兼容机 (1 . OX ) 速度较慢 , 运行大一点程序 (1 0 0 行 ) , 用户的心理压 力就很 大 , 一般应做心 理 调整或更换编译器。 表 2 中的数据表明更换编译器 可使 承 受 级 别 提 高1 、 2 级。 另 外一点是在上机前就应“ 明确” , 程序很大时 , 编译时间长 。

4、UN I X 分 时 系统影响 用户 心理 的讨 论 前面 已讨论过 , 分时系统对用户的心 理影响主要是机器 速度 , 其次是编译软件。 因而 除 更换 编译软件和心 理 自身调 节外 , 就必 须对机器更新换代了。 另外 , 笔者在 A ST 2 3 6 上调 试 1 0 0 0 ~ 2 0 0 0 行的模块时 , 发现 仍有较大的心理 压力 , 承 受级别 4 ~ 5 , 这也说 明心理 压力 的调节主要靠硬件更新 。
5、音响、 图像对心理 因素的影响 笔者对 4 名受测者测试 , 给受试者 M S一 O 和 T U R B O 一 O 二 种编译器 (受 试者 以前从未 使用过 C ) , 受试者都愿使用 T U R B O O , 理 由是 画面直观 , 操作方便。 但当笔者介绍 了 M S哪 . 0 的 O O D E V I E W , M A K E 和 Q i l t c k一 O 等后 , 受试者表示也愿意选择 M S 一 O 。

心理调节能力与衡量标准

表 1 中数据和实验 5 中相比较 , 可 以看出表 1 中承受级别的时间明显 高于实验 5 中数 据。 图 4 是 图 1 , 图 2 和图 3 的合成图。