简介面向北京交通大学“汇编与接口”课程的一份Debug调试实验文档以leapYear.exe闰年判断程序为例完整呈现汇编程序从编译、链接到运行调试的流程。文档从整体逻辑与逐句逐段分析两条线展开既说明闰年判定规则能被4整除但不能被100整除或能被400整除的编程实现又展示在Debug中观察是/非闰年输入时的寄存器变化与输出结果并介绍D显示内存、T单步执行、C继续运行、P执行指令等常用调试命令。针对实验中可能出现的判断条件不准、输入处理不当等问题还给出了定位思路与修改示范。资源以1个docx格式文档打包大小78.94MB目录涵盖编译运行、代码分析、Debug实践和错误修改四大部分便于按步骤对照上机操作。目前已有521人在CSDN平台学习下载适合作为微机接口课程实验的参考笔记及汇编调试入门资料。1. Debug 一跑就翻车leapYear.exe 直接运行全对进 Debug 后所有年份都变成闰年某高校的汇编与接口课程里有一道经典的 Debug 调试实验用 masm5 编译链接一个 leapYear.exe判断输入的年份是不是闰年。程序在 DOS 下直接运行输入 2020 输出闰年输入 2026、2025、2100 都正确输出不是闰年看起来完美收工。可一旦用 debug 加载它再用 G 命令跑怪事就来了输入 2020 显示闰年还能接受输入 2021 依然显示闰年更离谱的是不管输什么四位数年份结果全是闰年。这种“直接运行正常、调试环境才出错”的故障最折腾人第一反应往往是调试器坏了实际是一个寄存器初始化的隐含 bug。下面把整个定位过程拆开讲正被 Debug 单步卡住的初学者和想搞懂 LOOP 与 CX 关系的朋友都能照着查一遍。2. 根因MOV CL,[BUF1] 只改低位CH 残留让 LOOP 多循环了 0104H 次2.1 先看懂 DATACATE 子程序字符转数字的“乘十累加”leapYear.exe 的输入输出逻辑不算复杂。主程序先输出 “Please input a year:”调用 DOS 的 0AH 号功能把键盘输入的字符串读到缓冲区 BUF然后调用 DATACATE 子程序把字符串年份转成十六进制数存进 W再调用 IFYEARS 子程序做闰年判断最后根据 CF 标志位决定输出“是闰年”还是“不是闰年”。整个流程里DATACATE 是最容易藏问题的一段。缓冲区布局是BUF 处放最大长度 8BUF1 放实际输入的字符个数BUF2 开始放字符本身。比如输入 2020BUF2 到 BUF5 就是 “2”“0”“2”“0” 四个 ASCII 码。DATACATE 做的事是每次取一个字符减去 30H 得到数字再把上一次的累加结果乘 10加上新数字循环四次得到 2020DATACATE PROC NEAR LEA SI, BUF2 ; SI 指向输入的年份字符串 MOV BX, 0 ; BX 作为累加器先清零 X3: MOV AL, [SI] ; 取一个字符的 ASCII 码 SUB AL, 30H ; ASCII 码减 30H得到数字 0-9 MOV AH, 0 ; 把 AX 高位置 0保证 AX 里是纯数字 XCHG AX, BX ; 交换把累加值放进 AX 准备乘 10 MOV DX, 10 ; 乘数 10 MUL DX ; AX AX * 10结果存在 DX:AX XCHG AX, BX ; 乘完的结果换回 BX ADD BX, AX ; BX BX * 10 新数字 INC SI ; 指针后移处理下一位 LOOP X3 ; CX CX - 1CX 不为 0 则继续循环 MOV W, BX ; 最终年份送入 W RET DATACATE ENDP这段代码的逻辑是标准的“乘十累加”第一个数字进来时 BX 是 0乘 10 还是 0加上 2 得到 2第二个数字进来2 乘 10 加 0 得到 20BX 里存的是 0014H第三个数字进来20 乘 10 加 2 得到 202第四个数字进来202 乘 10 加 0 得到 2020也就是 07E4H。每一步都依赖上一次的累加结果这也是后面排查时观察 BX 值变化的关键依据。2.2 LOOP 的循环条件不是“低位为 0”而是 CX 整体不为 0问题就出在循环次数上。看主程序调用 DATACATE 之前的这一段MOV CL, [BUF1] ; BUF1 是实际输入的字符个数送入 CL LEA DI, BUF2 ; DI 指向缓冲区数据区 CALL DATACATE ; 调用子程序做字符转数字这里只给 CL 赋值没有给 CH 赋值。如果输入的是四位年份CL 变成 04H但 CH 保持进入程序之前的值。LOOP 指令的执行过程是先把 CX 减 1再判断 CX 是否等于 0不等于 0 就跳转到目标标号。注意这里的 CX 是完整的 16 位寄存器不是只看 CL 低 8 位。哪怕 CL 已经减到 0只要 CH 不是 0CX 整体就不是 0循环就会继续。这是新手最容易踩的认知误区。很多人把 LOOP 理解成“CL 减到 0 就停”看到 DEBUG 里 CL 变成 00 就以为循环结束了实际上 LOOP 判断的是 16 位的 CX。DATACATE 的累加器 BX 是 16 位乘 10 累加的结果一旦超过 FFFFH 就会溢出只保留低 16 位。2020 的十六进制是 07E4H如果继续按“20200、202000……”的节奏累加BX 很快就会溢出丢失高位最后得到一个看起来毫无规律的值。实验中观测到循环结束后 BX 71B0H就是这个溢出截断后的残留。2.3 根因定位直接运行时 CX 恰好为 0Debug 下 CX 被调试器占用为什么直接运行不出错进 Debug 用 G 命令运行就出错答案在 CX 的初始值上。DOS 加载一个普通的 .exe 程序时会按程序头的设置初始化寄存器CX 一般被置为 0所以 MOV CL,[BUF1] 之后 CX 高 8 位仍然是 0CL 变成 04HCX 整体就是 0004H循环正好执行四次结果正确。而用 debug 加载 leapYear.exe 时CX 存放的是文件长度等信息。实验中用 R 命令看到 CX 一开始就不是 0IP 指向 0000CS 段地址是 0C59H 这类和源程序里直接写的段地址完全不同的值。在这种环境下执行 MOV CL,[BUF1]只会覆盖低 8 位高 8 位保留着 debug 环境带来的残留值。假设 CH 是 01HCL 是 04HCX 整体就是 0104HLOOP 要执行 0104H 次才停。DATACATE 里的乘十累加在得到正确的 2020 之后根本停不下来继续循环 0104H 次BX 值越过 FFFFH 溢出截断最终定格在 71B0H。整件事的根因就是一句话代码在 DATACATE 循环前没有对 CX 高位清零依赖了“CX 初始为 0”这个外部条件。直接运行时条件恰好满足Debug 环境下条件被打破于是同一个 .exe 表现出两种完全不同的行为。定位到这一步修复方案已经很清楚了在 MOV CL,[BUF1] 之前加一条 MOV CH,0保证 CX 的高位永远是 0。这个实验也提醒我们汇编程序里所有寄存器的初始值都必须当作未知数处理不能赌它恰好是 0。3. Debug 实测R/U/T/P/G/D/E 指令如何把 71B0H 之谜一步步拆穿3.1 T 单步进入子程序观察 AL 减 30H 的 ASCII 转数字过程先用 debug leapYear.exe 加载程序再用 R 命令查看寄存器会发现 CX 一开始就不是 0。这说明 debug 环境确实改变了寄存器初值和直接运行不是同一个起点。用 U 命令反汇编能看到 CS:IP 指向的每一条指令地址方便对照源程序。接下来输入 T 指令单步执行T 指令的特点是遇到子程序会进入子程序内部所以它能带我们走进 DATACATE 的每一行。执行到 MOV AL,[SI] 时AL 变成 32H这是字符 “2” 的 ASCII 码。再执行 SUB AL,30HAL 变成 02H字符成功变成了数字。这个过程很直观30H 是字符 ‘0’ 的 ASCII 码任何数字字符减 30H 就得到它代表的数值。随后 MOV AH,0 把 AX 高位置 0AX 变成 0002H保证后续乘法和加法不会带入高位垃圾数据。通过 T 指令单步这些细节全部暴露在寄存器变化里。继续单步能看到 XCHG AX,BX 交换累加值MUL DX 做乘 10 运算ADD BX,AX 完成累加。前两位处理后 BX 是 0014H也就是 20第三次循环后 BX 变成 00CAH也就是 202第四次循环后 BX 变成 07E4H正好是 2020 的十六进制。到这里DATACATE 的算法本身没有任何问题问题只出在循环没有按时停止。3.2 循环异常BX 从 07E4H 一路涨到 71B0H四次循环之后按正常逻辑 LOOP 应该让 CX 减到 0 并跳出循环。但此时 CX 的高位 CH 还残留着 debug 环境带来的值导致 CX 减了四次仍然不是 0。用 T 指令继续单步会陷入无限循环按多少次都走不完。正确的做法是改用 P 指令P 指令和 T 的区别在于P 会一次性执行完当前指令遇到 CALL、INT 等调用时不会进入内部而是直接执行完整个调用返回。用 P 指令跳出循环后发现BX 的值已经变成了 71B0H而不是正确年份。这时用 D 命令查看内存能看到输入的数字已经放进缓冲区。实验里输入 2020 后数据段偏移 0050-0053 的位置存着 32 30 32 30 一排 ASCII 码说明输入环节没有问题问题集中在 DATACATE 的循环次数上。71B0H 的十进制是 29104这个数字和年份毫无关系就是累加溢出后残留的低 16 位。更关键的现象是输入 2021四次循环后 BX 是 07E5H继续用 P 跳出循环BX 还是 71B0H。用 2020 和 2021 两个不同的输入最终得到同一个 BX 值说明多出来的循环次数是固定的由 CX 初值决定。年份的低 16 位在溢出之后被丢弃所以不管输入是 2020 还是 2021只要前几步计算一致最终溢出的结果就一致。这就解释了 Debug 下“所有年份都显示闰年”BX 都是 71B0HIFYEARS 对同一个数做判断结果当然一样。3.3 E 命令篡改内存证明 IFYEARS 判断逻辑本身没有错为了确认问题只在 DATACATE、不在 IFYEARS实验里用 E 命令直接把 W 的内容改成 07E4H。E 命令可以修改指定内存地址的数据相当于人为给 W 写入了一个正确值。改完之后继续运行程序正确输出 “This is a leap year!”。再把 W 改成 07E5H也就是 2021 的十六进制表示继续运行程序正确输出 “This is not a leap year!”。这一步验证非常重要IFYEARS 子程序对 2020 判闰年、对 2021 判非闰年行为完全正确。也就是说闰年判断的算法没错错的是喂给它的数据。通过 E 命令绕过 DATACATE、直接给 W 塞数据我们把故障范围从整个程序缩小到 DATACATE 的循环控制排查思路也变成了经典的二分定位法。Debug 的 E 命令在实际排错里非常有用遇到可疑的子程序先手动改掉它的输入看看后面是否正常能快速圈定责任范围。3.4 G 命令与 P 命令的分工什么时候该用哪个整个调试过程中用到的指令分工值得单独记一下指令作用是否进入子程序/中断R查看/修改寄存器否U反汇编显示指令否D查看内存数据否E修改内存数据否T单步执行进入P单步执行不进入G运行到指定地址不进入T 和 P 的选择是一个常见困惑。需要进入子程序看内部每一行时用 T需要一步跨过整个子程序时用 P。在 LOOP 循环里如果确定问题出在循环次数上用 T 在里头死磕反而浪费时间用 P 一口气执行完循环直接看跳出后的寄存器结果效率更高。G 命令还可以配合地址参数使用比如 G 0018 表示运行到偏移 0018H 处暂停实验里就用它停在输出语句附近确认跳转方向正确。实验里除了这些还把 F、A、H、Q 都过了一遍。F 可以把一串内存填成相同数据A 可以直接在 DEBUG 里写一小段汇编H 用于计算两个十六进制数的和与差Q 退出调试器。这些指令单独练起来不难但真正理解它们各自的服务场景是在这种追一个 bug 追到寄存器层面的过程里。4. 汇编 Debug 避坑5 条新手最容易踩的调试误操作4.1 T 指令进入 INT 21H 中断后卡死现象主程序显示字符串和读键盘都要调用 INT 21H。用 T 指令单步一旦执行到 INT 21H就进入了 DOS 中断处理输入 T 之后没有任何反应甚至没法继续调试像是程序“卡死”了。原因INT 21H 是 DOS 系统功能调用T 指令遇到 INT 会进入中断服务程序内部。中断内部有大量我们并不关心的系统代码单步进去不仅没有信息量还容易因为缓冲区等待等原因卡住。解决遇到 INT 21H、INT 20H 这类软中断改用 P 指令。P 指令会把整个 INT 调用当做一个步骤执行完直接返回调用处不会进入中断内部。以后调试任何带 DOS 功能调用的程序都记住一个习惯看到 INT 就按 P不要按 T。这条是这次实验里实打实踩出来的血泪经验。4.2 P 指令不能进入子程序想观察内部必须用 T现象想查看 DATACATE 子程序内部每一句的执行效果用了 P 指令结果程序一步就跳过了整个子程序看不到 LEA SI、MOV BX,0 这些内部步骤。原因P 指令的设计语义就是“不进入调用”CALL 一条指令执行完直接停在 CALL 的下一条。它和 T 正好相反T 会进入 CALL 指向的子程序P 不会。解决看子程序内部用 T跨过子程序用 P。两者没有谁更好只有场景合不合适。判断当前用哪个就看你想不想要子程序内部的细节。另外从循环里跳出来时 P 很管用。实验里 LOOP 因为 CH 残留变成死循环用 T 永远走不到头用 P 一下跳出循环立刻看到了溢出的 BX 值。4.3 用 R 命令看寄存器别只看低 8 位就下结论现象调试中看到 CX 显示 0104H 之类某个瞬间 CL 变成了 00于是以为循环条件已满足可 LOOP 还在继续转。原因LOOP 判断的是 16 位 CX 寄存器整体是否为 0CL 只是 CX 的低 8 位。调试器显示的 CX 是完整 16 位值但人眼容易只盯住低位变化忽略了高位残留。实验中 CX 高位不是 0低位减到 0 后 CX 整体还是 0100H循环继续执行。解决所有涉及计数器的循环先用 R 命令把完整值记下来再跟踪变化。看到 CX 显示类似 0104H正确的解读是“循环还要执行 0104H 次”而不是“CL 是 04H 所以四次”。如果发现循环次数不对第一时间检查高位 CH手动算一下 CX 初始值别让“看着像 0”骗了你。4.4 U 命令反汇编地址与源程序行号对不上现象用 U 命令反汇编看到的地址偏移和源程序里标注的段地址、偏移对不上怀疑自己看错了代码。原因DEBUG 加载 .exe 后CS、DS 等段寄存器的值由程序加载时的内存布局决定源程序里 ASSUME 伪指令只是告诉汇编器逻辑上怎么安排实际地址以加载时为准。实验中 CS 从 0C59H 开始IP 从 0000H 开始和手工按段地址计算的绝对地址不是同一个数。解决不要试图把 U 命令的地址和源文件里的绝对地址一一对应直接用 U 命令现场反汇编出来的指令序列做对照看助记符和操作数是否一致。判断代码执行到哪一步以反汇编显示的 CS:IP 为准。这个现象不是程序错误是调试环境正常的内存重定位理解之后就不会再被绕晕。4.5 直接运行正常、Debug 才出错的程序优先怀疑未初始化寄存器现象leapYear.exe 单独运行2020、2026、2025、2100 全部判断正确用 debug 加载后用 G 命令运行无论输入什么都输出闰年。原因这是调试环境与运行环境的寄存器初值不一致造成的。直接运行时 CX 恰好是 0MOV CL,[BUF1] 后 CX 高位还是 0循环次数正确debug 环境下 CX 被调试器占用高位 CH 不为 0循环失控。程序对未初始化高位的依赖在正常运行时被偶然满足在调试时暴露。解决遇到这类现象第一反应应该是找哪个寄存器只写了部分。检查所有 MOV 到 8 位寄存器、而 16 位寄存器又没有先清零的指令。修复不复杂在 MOV CL,[BUF1] 前补一条 MOV CH,0 就彻底解决。从那以后我只要看到 8 位寄存器赋值用于循环计数都会先确认另一半是否清过零省掉很多无谓的怀疑。5. 修复加一条 MOV CH,0重新编译链接后验证三组用例5.1 最小改动MOV CH,0 加在循环计数之前定位到根因后修改方案非常小。DATACATE 的循环由 CX 控制而 CX 只有低 8 位被赋了值高 8 位是环境残留。只要把高位清零循环次数就完全由输入字符个数决定MOV CH, 0 ; 新增将 CX 高位置 0防止残留值干扰 LOOP MOV CL, [BUF1] ; BUF1 为实际输入字符个数 LEA DI, BUF2 CALL DATACATE这条 MOV CH,0 放在读 BUF1 之前或之后都可以只要在 LOOP 开始执行前完成高位清零即可。更稳妥的做法是直接用 MOV CX,0 先把整个 CX 清掉再 MOV CL,[BUF1]两条指令最直观。注意修改的是主程序中调用 DATACATE 之前的代码而不是 DATACATE 内部。DATACATE 里的 LOOP 本身没有错错的是它收到一个不干净的 CX。这里也顺带解释一个常见疑问为什么不直接改 LOOP 的判断条件因为 LOOP 指令的语义在 8086 里是固定的就是 CX 减 1、非零则跳转。它的设计前提是调用方必须保证 CX 是合法的循环次数所以修复责任在调用方不在 LOOP 本身。汇编程序里很多类似的坑都是被调子程序假设调用方初始化到位一旦假设被打破行为就不可预测。5.2 重新编译链接masm 与 link 的完整流程修改完源文件需要重新走一遍编译链接流程。实验使用的是 masm5 工具包先确认 masm5 文件夹在 C 盘根目录然后进入该目录操作。编译用 masm 命令汇编器读取 .asm输出 .obj 目标文件链接用 link 命令链接器读取 .obj输出 .exe 可执行文件cd C:\masm5 masm leapYear.asm link leapYear.objmasm 过程中会提示是否生成列表文件、交叉索引文件等按参考书要求生成 .lst、.crf 等文件方便查看指令地址和符号对应关系。link 成功后masm5 目录下会多出 leapYear.exe之前的 .obj、.lst、.ref、.map、.crf 也都会保留。提示DEBUG 加载的是链接后的 .exe不是 .asm 源文件。每次修改源文件后必须重新编译和链接再重新用 debug 加载新生成的 .exe否则调试的仍是旧程序。这里有一个调试实验特有的注意点DEBUG 的 T、P、G 指令操作的是机器码层面的指令和源文件的行号没有直接对应关系。所以修改完代码确认生成新 exe 后最好先用 U 命令看一眼第一条指令是否变化避免调试时拿旧文件重复碰壁。5.3 回归验证闰年、非闰年、世纪年三组用例修复后不能只看 2020 一个例子要按闰年规则的边界条件做回归。闰年的完整规则是能被 4 整除但不能被 100 整除或者能被 400 整除。所以至少测三组普通闰年如 2020普通非闰年如 2021以及能被 100 整除但不是 400 倍数的世纪年比如 2100再加上能被 400 整除的世纪年比如 2000这样四种情况全覆盖输入年份预期结果实际结果2020闰年闰年2021不是闰年不是闰年2100不是闰年不是闰年2000闰年闰年在直接运行环境下输入 2020 得到闰年输入 2026 和 2025 得到不是闰年输入 2100 得到不是闰年结果全部正确。再回到 DEBUG 环境重新加载修复后的 leapYear.exe输入 2020、2021、2100观察 LOOP 是否在四次后正常跳出。BX 的值应该精确停在 07E4H、07E5H 这些年份对应的十六进制数上不会再往 71B0H 跑。调试环境和直接运行环境的结果一致说明修复不依赖任何偶然的寄存器初值。这里也补一句E 命令修改内存的办法在回归测试里依然有效。如果怀疑 IFYEARS 对某个边界值的判断有问题直接用 E 命令把 W 改成 1900H 这类值快速验证不必反复从键盘输入。把改内存和重新运行结合起来能省下不少时间。5.4 为什么直接运行正确也要修防御性清零的习惯有人可能会说反正直接运行是对的Debug 只是调试工具不改也行吧。这个想法很危险。程序正确不能依赖于恰好没人用 Debug 跑它更不能依赖 DOS 加载后 CX 恰好是 0。寄存器在程序入口处只有 CS:IP、SS:SP 等少数几个有确定含义其余寄存器的值都属于未定义不同操作系统、不同加载方式都可能不同。今天 Debug 环境下出问题明天换了别的加载器可能又出问题。所以防御性清零不是洁癖是汇编编程的基本素养。所有用作计数、寻址、累加的寄存器和内存单元使用前都要明确初始化。这个实验的精髓其实不在闰年判断算法而在于展示一个隐蔽的初始化遗漏如何让程序在特定环境下全线崩溃。修复后哪怕直接运行结果没有变化也必须保留这条 MOV CH,0因为它消除的是一个潜在的随机故障源。6. 快速定位法以后再遇到“只有 Debug 才出错”的程序我这样查6.1 先复现再分辨是逻辑错误还是环境错误遇到调试环境才出错的第一件事不是改代码而是把两种运行方式的现象都完整记录一遍直接运行对不对、Debug 下哪个指令出错、出错时寄存器是什么值。如果两种环境结果不同基本可以断定代码依赖了外部环境提供的某个初始值。这时候把注意力放在“环境给了什么、代码又没设什么”上比盯着业务逻辑更有效。6.2 寄存器快照比对进调试器先看一遍完整值我一般会在程序入口处先用 R 命令做一次寄存器快照把 CX、DX、BX、SI、DI 五个寄存器抄下来。然后单步执行到可疑代码前再做一次快照两次对比差值就是代码对环境初值的依赖量。leapYear 这个 bug 就是这样暴露的入口处 CX 不是 0DATACATE 之前只写了 CL没动 CH差异一眼就能看出来。6.3 内存篡改验证把可疑子程序“短路”掉如果怀疑某个子程序产出的数据不对用 E 命令直接修改它的输出然后继续跑。改完后程序结果正确责任就在这个子程序改完后还是错就继续往前查。实验里把 W 改对后 IFYEARS 判断全对一下就把责任锁定在 DATACATE再把 CX 用 R 命令强制改成 0000 再跑同样得到正确答案进一步确认了根因。这个办法比反复单步循环高效得多尤其适合 LOOP 死循环这种没法用 T 指令走完的场景。从那以后我每次写汇编循环都强制自己在 LOOP 前检查一遍 CX 高 8 位每次进 Debug第一件事就是 R 看寄存器快照。这两个习惯救了我不少次。这份实验材料把每一步寄存器变化都做了对照记录跟着复现一遍比死记指令效果好得多。希望帮到你。本文还有配套的精品资源点击获取