是否有人见过多个调试器弄错了行号或被一个断点击中了？
我有一个多脚本（scripty.rc），该过程取决于在此程序结束时击中断点。该程序以两个循环之一完成：
:failure
6648 NOP
6649 b failure ; You are a failure
:complete
6650 NOP
6651 b complete ; Your program worked, rejoice
所以我应该在6649或6651上打破，为用户打印行，让他们验证一切都是笨拙的。
但是。
它不会在6651中破裂。至少并非总是如此。在午餐之前，请确保一切正常，我看到它像我想要的那样击中它。午餐后，当我与HW家伙一起演示时，它打印出来的线是6650 NOP。喜欢什么？真的吗？我在演示你的那一刻背叛了我吗？
我验证该软件是相同的，并且不是偷偷摸摸的提交。
我验证脚本相同。这并不是要设置另一个断点。
我用断点进行数学。在脚本中是bp _start#2135，是的，_start在4516中。是的，经过深入分析后，4516 2135 = 6651。
我看到它早些时候撞到了正确的行。
我很想把这个与多人的不健康关系粉笔。解决方法很容易，但是一个非确定性的调试器听起来很恐怖，我想将其运行到地面上。有没有人见过多重调试器会误认为线路号或被一个断点击中了？有人知道还有什么吗？我是在搞砸简单吗？
我找到了这个。这确实是愚蠢而简单的。
这就是多工作的方式。当您设置一个断点时，它会以procedure#123的形式记录它。123是从过程开始的偏移。我拥有的可爱工具是用ASM编写的，因此只有一个_start。
多数计数从1 开始的过程行。看一下多调试器的左侧。这也是"多：调试源窗格"中的帮助文件中。数字的最左列是文件行号。右侧的一个是"过程搭配线号"。
因此，在proc#1上破裂不会在过程中 1上破裂，它在过程中的第一行中打破。这并不是真正的偏移。我不想在4516 2135上打破，而是想在4516 2136th指令中打破。我不知道b _start#0会做什么。
在填写错误报告并在此处询问问题时，还有一个重要的教训。在上方，我输入了行号，但省略了以为它们并不重要的过程编号。