你碰到过的最难调试的 Bug 是什么样的？

2017年1月17更新

好像最近这个帖子又被翻出来了，又陆续有一些朋友点赞或者留下评论，谢谢大家！有一些大家共同关心的问题，我在这里做一些统一的回复，谢谢！

1. 那哥们后来怎么样了？

没怎么样，混的不错。去Intel继续祸害大众了，哈哈

2. 同行啊，请问答主目前哪里高就

现在混互联网。搞了家小公司。不写BIOS很多很多很多年了

3. 300万行代码如何编译成不足8m的rom?

这个问题问得很好。首先300万行的规模是整个项目的规模，里面包含有几乎所有硬件的platform code，事实上在每个特定的主板上，是要做一些裁剪的，把一些这个主板没有用到的硬件代码去掉；其次这300万行里面还包含所有的工具代码，makefile，配置文件等等等等，尤其是工具类的代码，除去编译以及连接工具，大概有几十个自行开发的工具要参与构建过程，整个BIOS的构建过程首先就是先构建这些工具，然后再用这些工具去处理配置文件，创建总的makefile，在一步步的逐渐的去创建各个模块的makefile，最后再根据最上一级的模块配置文件来逐步的构建每一个组件。当这些组件都生成了，再根据预先配置好的FLASH的存储结构，按照相关的规范来打包成ROM文件，压缩格式是略微调整过的LZMA，按照FFS规范来进行存储

我那个时候（2005年 - 2010年），编译工具用的是VS2003 + MASM；后来听说他们升级到了VS2010，貌似也可以用GCC了，好像也可以用Intel C Compiler

2015年8月23更新

评论里有几位朋友对于我提到的BIOS有上百万行源代码表示不可能，甚至有一位朋友提到BIOS就是个boot loader，要那么多代码干什么？我想我有必要在这里做一些简单的说明。

在说明之前，我首先要申明一下由于我2010年就已经离开BIOS行业了，并且之后的日子我并没有持续的去跟踪最新的技术趋势，所以我对于目前的最新情况并不了解，事实上这个行业的知识刷新速度看起来非常快。所以我这里说的其实还是基于我当年的知识构成。

首先，目前的BIOS都是基于UEFI的新一代BIOS。这类系统本身就具备十分强大的功能。完全可以视作一个小型的操作系统，有自己的shell，自己的drivers，自己的app，甚至自己的图形环境。这样的系统的代码量自然不会小。

其次是因为x86系统的历史包袱非常非常严重，而bios作为最核心的系统固件承担了太多的历史兼容性的责任。举个例子，就是对于usb键盘的支持，大家可能会简单的认为，支持一个usb键盘那不是太简单的事情么？的确是这样，但是个人电脑有一个非常非常重要的原则就是兼容性。具体到键盘上，如果你现在找一个古董级的PS/2接口的键盘，然后把它接到现代的主板上，假如你的主板已经没有PS/2接口了，那么买一个转换头，然后再接上去你会发现这个古董级的硬件仍然可以使用。是的！对于我们用户而言，这是完全符合逻辑的一件事情。但是对于bios开发者而言，这就是一个很要命的问题了。原因很简单，我们暂时穿越到几十年前，那个年代的电脑主板上都有一个叫做8042的芯片，用来控制诸如键盘这样的外设，那个时代的开发者通过读写60H以及64H端口来访问键盘，然后那个时代的汇编BIOS则提供了INT 9H中断来为应用程序提供键盘服务，在几十年前那个时代，这一切是很美好的。那个时代的操作系统DOS就是这样来访问键盘的。现在让我们回到更加美好的现代，由于历史兼容性原则，所以现在的每一台计算机还必须可以安装DOS，还必须让DOS或者运行在DOS之上的应用程序可以无差别的运行在现代的计算机之上 - 可是，大家是否知道，现代的计算机压根没有8042这块芯片！更要命的是，后来人们发明了一个叫做USB的新玩意儿，基于这个新玩意儿的键盘根本不会接到60/64端口上，而且这个新接口的键盘采用的编码与过去PS/2接口的编码完全不一样！那么如果不做任何处理的情况下，那些过去年代的软件压根不会认识新的键盘，所谓的历史兼容性根本无从谈起！所以我们伟大的bios这个时候就扮演了救世主的角色了，bios会做很多处理，以现在的角度看，现代bios模拟了一个PS/2键盘：现代bios一边读取来自USB键盘的信息，一边将其转换成那些古老软件能够识别的键盘编码，然后再中断系统，写入内部的60/64端口的缓冲区。大家也许会发现，所有的现代bios里会有一个设置项，一般叫做legacy USB Support，默认值就是Enable，打开这个选项你才可以在DOS下使用usb键盘。当然，具体的实现过程异常复杂，涉及x86处理器最神秘的SMM模式，我们就不展开讲了，这已经远远超出本文的初衷。所以一句话，bios的代码非常复杂，还要包含大量的历史兼容性代码，除了我们上面谈及的键盘问题，还包括比如INT 10H的屏幕服务，据说直到Windows 7的安装程序，还有一小部分使用INT 10H来写屏。那么我们的bios就必须包含这些可能有些用户一辈子也用不上的服务。代码量刷刷的就上去了。

--------------------------

每次想起这个bug，虽然很多很多年了，我仍然满脸都是泪水啊！

当年做x86 BIOS，客户是长城电脑。有一回我们的新版本发布给他们后进行系统重启测试，就是安装好操作系统后反复不停的重启机器，看看重启几百上千次后情况如何。原因是客户买了电脑每天用，至少得保障人家用个俩三年没事吧。

结果我们的新版本重启到一百多次的时候挂了，现象就是开机黑屏，没有任何输出，就和当年的CIH病毒发作一模一样，经验判断系统压根还没有boot OS就跑飞了，我们自己测试也是这样，而且一旦出现问题就只能重新刷BIOS

这个bug非常难调，因为当时我们的版本将近300万行源代码，大概2%的汇编与98%的C，几千个源文件，光是用来参与build过程的工具就有十几个。而且这些工具都是自己写的，构建项目的时候先编译这些工具，再去用这些工具加编译器来生成最后的ROM文件

并且更加恼人的是，我们当时没有source level的debug tool，甚至连汇编级别的单步调试工具也没有，压根没法对代码做step into/over，更没法加个断点。。。当时可以用来调试BIOS的工具有两个，一个是Intel自己内部用的ITP，这个是人家公司自己的，一般不给外面人用，当时我们公司与I公司的关系尚处蜜月期，给了我们两个，但是当时被Chipset team霸占着做porting用；另一个工具就是American Arium（这家鸟公司不知道现在还活着不），这个东西说白了就是商品化的ITP，因为目标客户少，所以价格巨贵巨贵！一套系统价格几万美金，而且每一代CPU都要换一个插座上的适配器，这个适配器又是一万美金好像，还不太稳定，用着用着就挂了。。。我们公司当时有俩，但是因为没有买新一代处理器的适配器，于是只能吃灰了

于是我们唯一的调试手段就是serial debug，就是系统启动的时候会通过port 80把一些重要信息打出来，然后我们根据这些信息判断执行到哪里了，系统的情况如何。这类似原始的printf打印。如果要看一个变量的值或者验证一下我们的判断，就得重新写代码，在需要的地方加入调试语句，然后花上半个小时rebuild bios，再重新烧录，再上电运行看看打出来的到底是啥。如果有疑问，或者发现这里没有问题，又或者有了新的思路，重复上述过程。记忆中整整一个礼拜，我们都在不停的看debug info，反复烧录bios 哭啊！简直不是人过的日子！

最后发现系统可以成功的跑过PEI，到了DXE阶段的某个环节，突然就像心脏骤停一样，跑飞了！去看疑似跑飞的DXE Driver，是个很普通的平台硬件初始化程序，没什么疑点，压根没有头绪。那段时间，几乎每时每刻都在想着这个bug，实在是茶饭不思，根本没心情做任何事！

就这样差不多过了俩礼拜，经过了无数次的重启与烧录bios，以及猜测，验证，被否定，再猜测，再验证，再否定。。。。。的过程后，我们终于发现了问题的原因：

大家可能还记得电脑主板上有个CMOS，传统上用来存bios设置，但是现代的系统已经逐渐弃用这个东西。我们现在的bios芯片都是可擦写的，也就是用程序可编程。bios大小是8MB，里面会规划好，哪里是code，哪里放设置等等，然后代码里有专门写flash的函数，让大家可以保存一些东西，比如你想用硬盘还是光驱启动等等。同时系统每次启动也都会自己写一点没什么鸟用的信息进来。

问题就出在这个写flash的函数上，我们后来发现，这哥们算错了存储区域的地址，导致写很多次后终于越界，误写到了人家代码区，把人家好端端的代码给写的乱七八糟，就如同当年CIH破坏系统的方法一模一样，照这样哪个机器能点亮才怪呢！又因为每次系统写的信息不一样，比如启动时间就不太一样，所以越界需要的次数不是恒定，更加重了我们排错的难度，泪啊！

第一次写这么长的回答，还是手机打的，累！

我印象里面最难调试的两个bugs，都和硬件有关，但最终都可以通过BIOS来打补丁。

悬丝诊脉

某著名公司还未上市的笔记本出了问题，在-10度的低温下经常莫名其妙死机。我作为BIOS专家，被千山万水召集到它的总部进行联合调试。在前台签署了一堆文档后，两个员工陪同我进入了一个大实验室。一进入实验室，画风突变，本来应该光洁明亮的房间，黑色的幕布从房顶垂下，将房间分割成十数个小间，像在进行敌特工作。在被引入需要工作的小间时，我要被气笑了。只见一根黑色的USB线从另一个小间连出，接在一台笔记本上。我被告知，只能在这台指定的笔记本上工作(我自己的不能用)，目标机因为机密，不能看，更不能碰！

都说BIOS调试和看病一样，讲究望闻问切，但这种只在传说中给闺中小姐，悬丝诊脉的情景，却在这个号称高科技公司中演绎地活灵活现。我心中暗自盘算，该公司不是中国公司啊，为什么是个中医粉呢？看我面色不善，他们以为我受到了冒犯，解释道：“no offense, it applies to everyone, include us.”其实我是被该公司著名的保密文化震撼了。后来才知道，在幕布后面，机器上还套个假壳子，他们自己人也看不到真容。

闲话休提，开始工作，于是发生了以下有趣的对话：

“死机死在哪了？”

“死在操作系统里。”

“你知道我不能看贵公司的操作系统源码，而我是个搞BIOS的吧！”

“操作系统没有变，一定是BIOS出问题了！”

好吧，我又要被气笑了。硬件一定变了吧？操作系统能支持新硬件码？为什么总是BIOS背锅？！没办法，调试手段有限，只有硬看了。经过两天两夜的调试，通过重建调用栈，寄存器对比等发现，原因是连接CPU和PCH的DMI总线太长，比Intel推荐的要求长了一点点，相信是主板布线时受到些硬约束，硬件工程师觉得长一点点不碍事。就是这长的一点点，导致在低温下，信号完整性不佳，而出现错误，最终操作系统读取硬盘时报错。

解决的办法是BIOS先给DMI降频，继续验证。产品版不得不再做一次FAB，多一次验证。成本增加了，上市也延迟了一点。

令出多门

某次主持开发一款E3主板。进度顺利，接近尾声。产品beta过后要进行压力测试，需要通过5000次soft reset，5000次hard reset，5000次Linux关机/启动，5000次Windows关机/启动，5000次UEFI Shell关机/启动。而在这个时候出了问题，在2000次左右关机/启动后，经常死在BIOS的内存初始化阶段，而且只有Windows/Linux会出现，重启和shell都是好的。

事关BIOS，我当然责无旁贷，组织了个攻坚团队，包括BIOS、硬件、操作系统、BMC和ME工程师。于是每天开会，每天跟踪进度，联合诊断。事情的难点在于每次关机/启动要3到5分钟，2000次需要3天多的时间。一次改正后，反馈周期太长。我不得不安排了6台机器进行迭代测试，安排不同部分的人分别盯守。

初步几天过后，分析下来是BIOS在读取spd信息时出错了。但为什么是关机/启动才出错？为什么开始不出错2000次后才出错？smbus读取代码十分简单，用过了很多代，为什么现在才出错？我仔细检查电路图，发现这代主板硬件工程师为了省事，将smbus的线都连在了一起，让BIOS、ME和BMC都可以访问内存信息，BIOS可以读取spd，ME和BMC可以读取内存温度，多方便！

smbus支持多host，硬件工程师这样做，也未尝不可。但ME、BMC和BIOS的祖传代码却缺乏相应支持，于是开会内容变成了各种争吵，事关谁该让一让的问题。最后决定大家都加上退避算法，解决总线冲突问题。

由于每次尝试都要等待好几天，加上牵扯方面太多，整个问题解决下来耗时一个多月，终于在产品发布之前，软件解决了问题。为此所有人出去大肆庆贺了一番。这个bug是我职业生涯中耗时最久的bug。

欢迎大家关注我的专栏和用微信扫描下方二维码加入微信公众号"UEFIBlog"，在那里有最新的文章。同时欢迎大家给本专栏和公众号投稿！