Debug调试实验全指南：从寄存器现场到端口状态

简介汇编与接口课程配套的调试工具实验资源源自北京交通大学汇编与接口实验以闰年判断程序leapYear.exe为主线面向正在学习汇编语言、微机接口及上机调试的学生帮助理解从编译链接到运行调试的完整链路。资源包为docx格式实验报告共1个文件压缩后大小78.94MB内容涵盖程序编译链接步骤、代码整体与逐段逻辑分析、调试工具中闰年与非闰年输入下的动态调试过程以及常见编程错误的定位与修改方法并补充了显示内存、单步执行、断点继续、执行机器码指令等常用调试指令的实践说明。已有521人学习下载适合需要系统掌握调试方法、完成课程实验或深入理解汇编程序运行机制的学习者可对照文档逐步操作有效提升底层排错与问题分析能力。1. Debug调试实验到底在调什么从寄存器现场到端口状态当你第一次在汇编与接口课程里接触Debug调试实验大概率不是让你写一个完整程序而是要求你在DEBUG环境下输入几条指令、单步执行然后记录AX、BX、CS:IP的变化。这个实验看起来轻巧却是很多人从“会写汇编语句”到“真看懂程序怎么运行”的分水岭。因为DEBUG会把CPU执行指令时的寄存器现场、内存字节和端口响应都摊开在屏幕上等于把黑匣子掀开了。Debug调试实验解决的核心问题有两个一是程序跑飞时能定位到具体指令二是程序与外设打交道时能直接观察端口状态。对正在做课程实验的学生、刚接触底层开发的从业者以及想搞懂中断、时序和接口芯片控制的嵌入式新人这个实验都值得认真做完。这篇文章按我的实操习惯从环境搭建、命令速查、接口实验应用到边界参数和常见坑整理成一条可以直接复现的路径。2. 实验环境准备与Debug命令速查用模拟器跑通最小调试闭环Debug本身是一个16位的DOS程序基于INT 21h和BIOS调用直接跑在现代Windows的命令行里多半会闪退或无法操作端口所以实验环境通常有两种选择一台真实的老式DOS机器或者一款常见的DOS模拟器。我一般会选后者原因不是怀旧而是调试时CPU频率太高会导致单步操作跟不上模拟器反而能把这些参数调下来。2.1 环境选型为什么我用模拟器做Debug而不用虚拟机虚拟机确实能装一个完整的DOS系统但启动需要几十秒安装驱动、调整内存、共享文件都比较重。DOS模拟器轻量、秒开还能把当前目录直接映射成C盘非常适合做Debug调试实验。唯一要注意的是模拟器对某些特殊指令比如端口IO、定时器中断的行为和真实硬件有细微差别所以在涉及硬件时序的实验里我会先用模拟器调逻辑再到实验箱上验证参数。在模拟器里跑Debug的步骤很简单先把实验目录挂载为C盘进入目录后输入debug回车。我习惯在配置里把内存设为4MBCPU周期设在3000附近这样单步执行时不会出现“一步迈过去三条指令”的玄学问题。如果模拟器支持动态编译调试时最好把动态核心关掉否则寄存器现场会跳变T命令单步的节奏也会不稳定。挂载目录时用mount c ./work把当前工作目录映射为C盘然后用c:切换盘符。注意不要试图在模拟器外直接运行DEBUG很多系统提示“找不到文件”并不是文件不存在而是64位环境缺少对16位程序的NTVDM支持。如果在模拟器里出现Bad command or filename先检查挂载路径里是否包含中文或空格路径越短越好。2.2 先背下这批命令A、T、G、U、D、E、RDebug实验里真正高频的命令不超过10个我把它们分成三组写入组、执行组、观察组。写入组负责把汇编助记符变成机器码和修改内存执行组控制程序从哪开始跑、跑到哪停观察组让你在每一步之后看到寄存器和内存。先背熟这组命令再谈调试。命令作用典型例子A以汇编助记符写入指令到内存a 100T单步执行并显示寄存器现场tG连续执行到断点g 120U反汇编内存u 100 10AD以十六进制和ASCII显示内存d 200E修改内存字节e 200 41 42R查看或修改寄存器r axI从端口读一个字节i 300O向端口写一个字节o 300 0AQ退出Debugq命令不区分大小写。地址默认使用DS段如果省略地址很多命令会沿用上一次操作结束后的地址。这个“沿用”机制对D命令特别有意义——连续敲两次D第二次显示的是上一次结束地址之后的128字节而不是同一段。有同学以为D出来的就是“整个内存”实际上它只显示一小块连续区域这个误解会在调试数组时浪费很多时间。T命令是Debug调试实验的灵魂。它执行当前CS:IP指向的一条指令然后打印所有寄存器的值和下一条指令的反汇编结果。因为每执行一条都会刷新屏幕所以它天然适合逐条观察标志位和状态变化。但它的缺点也很明显遇到CALL、INT指令时T会钻进子程序或中断处理程序内部而不是一步跨过这常常把新手带进“一大堆看不懂的BIOS代码”里。后面避坑章会专门处理这个问题。2.3 最小调试闭环从A命令写入一段指令用T单步执行用D查看内存为了让你马上有一个可复现的起点我们做一个最简单的实验把两个十六进制数相加放到AX里。打开Debug后先输入a 100这里100是偏移地址段地址用当前CS然后逐行输入三条指令最后空行结束输入。-a 100 mov ax,1234 mov bx,5678 add ax,bx -t AX1234 BX0000 CX0000 DX0000 SPFFEE BP0000 SI0000 DI0000 DS0B2F ES0B2F SS0B2F CS0B2F IP0103 NV UP EI PL NZ NA PO NC 0B2F:0103 MOV BX,5678注意代码块里的段地址0B2F只是示例不同环境、不同加载顺序都会变不能照抄。A命令写入的机器码从CS:0100开始T命令首次执行的是mov ax,1234执行后IP变为0103所以第二行显示的下一条指令是mov bx,5678。Debug把“当前状态”和“下一步要执行的内容”同时展示这正是判断程序流程的关键。继续按两次T执行完mov bx,5678和add ax,bx后AX应该等于68AC。如果看到别的值先检查是否在A命令阶段把指令写错或者某次T命令实际执行了两条。可以用r ax直接查看寄存器值也可以用u 100反汇编当前区域确认机器码与源码对应。这种“结果复核”动作在Debug调试实验里比命令本身更重要。再验证内存写入与读取输入e 200 41 42 43把三个十六进制字节0x41、0x42、0x43写入DS:0200开始的内存然后输入d 200 202。DEBUG的D命令范围写法是“起始地址 结束地址”结束地址包含在内这里会显示三组字节右侧ASCII对应ABC。这样一小段流程包含了写入、执行、观察三种操作可以作为后续实验的最小模板。3. 把Debug用进接口实验端口读写与状态寄存器现场普通程序调试只关心CPU内部接口实验多了一个外设维度。汇编与接口的Debug调试实验中很大一部分操作不是在调算法而是在核对端口地址、控制字和状态位。Debug在这里的角色从一个“指令级调试器”变成“寄存器级总线分析仪”这正是它不可替代的原因。3.1 接口实验和普通程序调试的区别Debug直接操作端口CPU和外设通信靠IN/OUT指令DEBUG对应I命令和O命令。这两个命令在普通Debug教程里常被一句带过但接口实验里是主角。很多同学第一次做并行接口实验时面对一堆“控制字”“状态字”不知从何下手其实用DEBUG的I/O命令可以绕开完整源码直接验证硬件通路。假设实验箱把并行接口的数据端口映射到0x300控制端口映射到0x303具体地址以实验指导书为准。初始化时一般要先向控制端口写入工作方式字用O命令执行-o 303 80 -o 300 5a -i 301第一行是向控制端口0x303写入0x80通常代表选择基本工作方式第二行向数据端口0x300写入0x5A用于观察LED或数据线上的电平第三行从状态端口0x301读入一个字节并显示。O命令语法是o 端口地址 数据I命令是i 端口地址端口地址范围是0x0000到0xFFFF数据只支持一个字节。流程上的重点是先控制字再数据字最后读状态字顺序不能颠倒。这里要强调一个反直觉的点如果端口地址错误DEBUG不会报错指令照常执行但硬件没有任何反应。读端口返回的0xFF也不一定是“设备不存在”可能是总线浮空。因此在接口实验里调试端口地址、数据方向、数据格式三条信息必须同时核对缺一条就会陷入“读不到值”或“设备不工作”的困惑。我见过某同学调了两天最后发现是控制端口地址比手册上多算了1单步一查立刻露馅。3.2 用Debug观察标志位ZF、CF、SF在状态查询里的角色接口实验的状态查询经常用IN读回状态字节再用TEST或AND去测试某一位。Debug的T命令执行后会显示标志位集合例如开头那个例子里出现NV UP EI PL NZ NA PO NC。每个字母对代表一个标志位NV表示不溢出UP表示方向递增EI表示中断允许PL表示符号为正NZ表示非零NA表示无辅助进位PO表示奇标志为奇NC表示无进位。在状态查询里最关键的是ZF和SF。举一个典型的查询循环程序从状态端口读取一个字节执行TEST AL,80H如果最高位为0则继续查询为1则进入数据处理。用T命令单步执行到TEST这条指令时观察ZF标志是NZ还是ZR。如果读到的字节最高位为0TEST结果应为0ZF1屏幕显示ZR如果最高位为1ZF0显示NZ。SF则会显示PL或NG反映测试结果最高位。这两个标志的切换能直接告诉你是设备还没准备好还是地址读错了位置。比打印输出更直观的是用单步观察数据本身。比如AL读回来是0x00那你应该立刻怀疑状态端口地址对不对而不是继续纠结程序逻辑。DEBUG把这一步变成了“看寄存器值是否合理”比事后分析打印日志高效得多。尤其在课程实验中状态位定义经常被看错单步观察标志位能帮你省下大量反复烧写和重启的时间。3.3 把汇编源程序和机器码对应起来U命令反汇编的价值实验报告通常会要求写出每条指令的机器码。与其手算指令编码不如用U命令直接反汇编。U命令把一段内存中的字节翻译成汇编助记符并显示地址、机器码和助记符三列。比如下面这段-u 100 10A 0B2F:0100 B83412 MOV AX,1234 0B2F:0103 BB7856 MOV BX,5678 0B2F:0106 01D8 ADD AX,BX 0B2F:0108 CD20 INT 20这里B83412就是MOV AX,1234的机器码注意立即数以小端序存储所以1234在内存里是34 12。B8是MOV AX, imm16的操作码34 12是立即数低字节在前。CD20是INT 20通常在DEBUG环境中作为程序正常退出的中断指令。如果实验环境不允许执行INT 20也可以忽略它只在报告里记录反汇编结果。使用U命令时有一个容易误会的点如果对数据区反汇编会出现一堆毫无意义的指令比如用E写入的0x41会被译成INC CX。这不是环境出错而是因为U命令只是机械地把任意字节当指令解释不知道哪些是数据。正确做法是先确定CS:IP范围再对代码区做反汇编。反汇编结果比你手算多了一条“桥”的作用你可以从机器码反推出每一条指令长度从而理解IP如何递增这对后续设置G命令断点、计算偏移地址非常有帮助。4. Debug调试实验避坑指南段地址、单步中断和端口挂起做Debug调试实验最常见的翻车点不是不会命令而是对16位实模式的段寻址和中断机制缺少直觉。下面这四条是我在实验课上见过、也自己踩过的坑每一条都按现象、原因、解决三个层次写清楚。这些经验值不是从手册里搬来的是在反复跑飞和重启模拟器中换来的。4.1 寄存器初值与CS:IP不是你想的那样现象刚进入DEBUG执行r查看寄存器发现CS、DS、SS都是同一个值比如0B2FIP是0100看起来一切正常。于是直接a 100写入指令再g 100运行结果程序不是报错就是跑飞。原因DEBUG启动后CS:IP指向的是DEBUG内部使用的代码区域不是你的程序起始地址。A命令默认在CS:100写入但这只是“DEBUG带你在的一个位置”并不等于程序的段重定位。如果你用MASM或TASM生成过EXEDEBUG加载后DS和CS通常不一致DS指向EXE前缀CS指向代码段两者偏移完全不同。解决进入DEBUG后先r看CS和DS再决定用a 100还是先修改DS。写指令后用u 100确认机器码真的落在你预期的地址。对于EXE程序更稳妥的是用U命令查看程序入口附近的指令再用G或T运行。另一个被忽视的初值是SP。DEBUG启动时SP指向DEBUG自己的栈顶如果你用A命令写了一段含CALL或PUSH的程序并执行栈操作会覆盖DEBUG内部数据导致后续调试行为怪异。所以做子程序调用实验时我会先用r sp设置一段安全栈空间比如让SP指向一个独立内存区域。这看起来麻烦但能避免一个非常难查的随机翻车。4.2 T命令单步把程序走进中断向量表现象用T命令逐条执行到INT 21H按下T后没进入你的下一条语句反而跳到一段完全看不懂的BIOS/DOS代码寄存器被改得面目全非屏幕显示一堆奇怪的INT指令。原因T命令会跟踪进入中断处理程序并单步执行中断内部指令直到遇到IRET返回。这不是故障是DEBUG的正常行为。但在接口实验中中断处理程序内部常有时钟和屏幕刷新代码单步进去会打乱你对程序流程的判断。解决遇到CALL、INT这类指令改用P命令Proceed。P的行为和T类似但会把CALL、INT、LOOP这类整体当作一步执行完然后停在下一指令。很多教程只讲T不讲P这是Debug调试实验的经典盲区。比如执行INT 21H用P一步跨过用T则钻进系统深处两者差别就是“步进”和“步过”。另外如果你单步进入了某个中断但想退出可以用G并设置断点到IRET返回地址或者在中断处理程序内部用T慢慢走回。最省事的方法是退出重来重新加载DEBUG并设置好IP。血泪经验是不要在中断服务程序内部胡乱修改寄存器否则可能直接把系统状态改坏导致模拟器卡死。4.3 G命令断点设错程序跑飞现象设好断点后执行g 120程序没有在地址0120停下反而直接运行到“Program terminated normally”或者屏幕输出乱码。原因G命令的断点地址是CS:IP偏移必须基于当前CS段。如果程序在运行过程中修改了CS或者你从DS段偏移想当然地设地址断点自然不命中。另外G命令下断点时会临时把断点处指令替换成中断指令如果程序执行路径根本没经过那里断点就不会触发。解决优先使用g起始地址 断点地址明确告诉DEBUG从哪一个IP开始跑、在哪个IP停。例如g100 120。如果程序会修改CS要先确认代码是否在同一个段内或改用U反汇编查看当前CS的值。接口实验中常见场景是中断服务程序和主循环在不同段断点必须分别按段设置。多断点的记忆点要特别说一句不同版本的DEBUG对G命令支持不同有些支持一次下多个断点有些只认第一个。如果你的实验在多个分支上都要停最保险的做法是一次只设一个断点另一个用T单步走过去。夹带大量断点反而可能因为程序没经过某个断点地址而出现“提前终止”的假象。4.4 用I/O命令直接访问端口导致模拟器或系统挂起现象敲o 378 FF想点亮并行口上的LED结果屏幕卡住或模拟器崩了。原因0x378是PC标准并行口的地址但很多模拟器并未完整模拟该硬件写入值可能触发一个未实现设备的中断循环导致死机。在真实DOS系统上错误写端口可能直接改变中断控制器或定时器状态让你再也敲不进命令。解决在使用I/O命令前先看实验箱或开发板手册确认端口地址映射。模拟器里不要随便访问未占用的端口先用I读一下地址如果返回0xFF且连续读都相同说明该端口没有被模拟干脆放弃。如果程序跑飞需要立即复位优先用模拟器自带的退出或重启功能这是最便宜的后悔药。另一个现象是读端口总是0xFF或0x00按键或设备状态没有变化。原因除了地址错误还可能是因为I命令只读一个字节而设备状态需要读入后配合控制信号才能更新。很多接口实验要求先写控制字再读数据端口顺序反了读到的永远是垃圾值。解决把初始化控制字写入流程用脚本固定下来每次读取前重放避免手动敲错顺序。我见过某同学每次读到的数据都差一位最后发现是方式字写成了0x00把I/O方向全配错了这只能用对照表逐位排查。5. 从会按命令到会排错Debug实验的验证方法与进阶用法命令背熟只是起步Debug调试实验真正拉开差距的地方在于验证方法。同样是调一个循环搬数据有人反复改源码重跑有人用两次内存快照直接锁定越界点。这一章把我在实验里反复用到的验证技巧整理出来每一步都可以直接抄。5.1 用地址快照比对验证循环和数组移动是否越界在字符串搬运、数组赋值这类实验里越界是高频错误。Debug的D命令可以快速记录某段内存的完整内容我习惯在循环执行前和循环结束后分别做一次“快照”对比源区域和目的区域的数据。比如数据段DS:0200到0203是源数据移动目标在DS:0300到0303搬移前执行d 0300 0303搬移后再次执行看内容是否一致。如果目的区域末尾多出几个字节就说明循环次数或偏移计算多了。快照对比还有一个变体观察内存中的ASCII字符。E命令写入几个字符后用D命令查看右侧ASCII列可以直接看到字符串是否被正确转移。接口实验里常需要把一段ASCII码发给外设显示或比较这个技巧比看十六进制更直观。要注意D命令显示的内存范围有限通常显示“起始地址到结束地址”或者从当前地址开始显示128字节所以快照前先算准区间别漏掉边界。5.2 用E命令和F命令构造边界测试数据在Debug实验里手动输入几十个字节既慢又容易错。E命令适合逐字节写入比如e 200 01 02 03 04F命令则适合用同一个值填充整段内存比如f 200 210 00会把DS:0200到DS:0210之间的17个字节全部写入0x00。F命令的语法是f 起始地址 结束地址 数值结束地址包含在内。这个操作在测试LED流水灯时非常实用想让我输出全0或全1一条F命令就能完成填充。构造边界数据时我会同时用到E和F。比如测一个排序程序先用F把数据区填成0x7F或0x80这样的极值再用E修改几个关键位置制造“相等”“逆序”等形态。F命令把大量重复数据准备好E命令针对关键位置做精修这样搭建测试用例的速度比在汇编源码里逐条初始化快很多。这类操作也能直接放进后续的自动化脚本实现数据准备的可复现。5.3 组合使用U和G快速定位死循环位置死循环在接口实验中最常见比如等待状态位跳变而设备始终不响应。用Debug定位死循环有一个标准套路先用U命令反汇编当前CS:IP附近的指令通常能看到一条跳转指令比如JMP 0100或LOOP 0100然后记下这个目标地址用G命令设断点并执行。如果程序停在同一个地址反复循环说明循环条件没有改变。更直接的做法是连续按几次T单步观察IP是否在两条指令之间来回跳。比如一个空转等待循环反汇编后总是IN AL, 端口、TEST AL,80H、JZ 地址这三条反复执行T几下就能看出来。死循环的原因通常是状态位条件永远不满足这时别急着改程序先用I命令手动读一下状态端口确认硬件是否真的给出了预期状态。DEBUG把软件循环和硬件状态同时放在你面前是综合排错的最佳工具。5.4 在接口实验中用循环单步配合状态端口变化画出时序图接口实验经常要观察外设的忙闲时序比如查询式传输里状态位何时拉高、何时拉低。Debug的T命令可以一条条执行同时用I命令读状态端口把每次读到的值记录到一张表里就能形成一份简单的时序图。下表是一个示例记录格式执行序号当前IP状态端口值ZF/SF标志判断结果101000x00NZ设备忙201030x80ZR设备空闲301060x00NZ忙这种记录方式适合慢速设备或模拟器环境因为T命令的单步频率并不高如果设备状态变化非常快单步会错过中间过程这时就要改用G加断点的方式采集多个关键点。画时序表的最大好处是写实验报告时可以直接引用每次单步的数据而不是模糊地说“程序工作正常”。对理解“状态查询”这种基本通信方式这份记录比任何流程图都更有说服力。6. 一个让我少走弯路的Debug自动化技巧用输入重定向做回归当实验需要反复敲同样一串命令时我养成了一个习惯把DEBUG操作序列写进文本文件用输入重定向执行。DEBUG在DOS下读取标准输入所以debug cmd.txt可以自动跑完整段操作。这不仅省去重复输入更重要的是让每一次调试的状态可复现方便对比修改前后效果。假设你要反复验证一段数据搬运代码可以建立一个名为test.txt的文件内容如下f 200 20F 00 e 200 41 42 43 44 a 100 mov si,200 mov di,300 mov cx,4 rep movsb g100 10A d 300 303 q在模拟器的C盘目录下执行debug test.txtDEBUG会自动载入并执行到q退出。需要特别提醒的是A命令后的空行不能省那表示汇编输入结束如果文件末尾不加空行部分DEBUG版本会一直等待输入。我第一次用这个技巧时脚本每次都在A命令后卡死后来才发现是空行缺失。执行结果可以重定向到一个文件比如debug test.txt result.txt然后把两次修改前后的结果文件用文本对比工具比较。这就是一种最朴素的回归测试代码改了但输出必须保持不变。接口实验中我会把端口初始化、数据写入、状态读取都写进脚本既能快速重放也能确保每次测试前设备状态是干净的。这个技巧让我在课程验收时少走了很多弯路也让我明白Debug调试实验的终点不是把程序调通而是建立一套可以反复验证的调试习惯。希望帮到你。本文还有配套的精品资源点击获取