0

有没有人见过 Multi 调试器的行号错误或断点被一个击中？

我有一个 MULTI 脚本 (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 处突破。至少并非总是如此。午餐前，当我确保一切正常时，我看到它就像我想要的那样击中它。午饭后，当我和硬件人员演示它时，它打印出来的行是6650 NOP. 比如什么鬼？真的吗？我演示你的那一刻你就背叛了我？

我验证软件是相同的，它不是一些偷偷摸摸的提交。

我验证脚本是一样的。这不像是设置了不同的断点。

我用断点做数学。在脚本中bp _start#2135是，_start是的，在 4516。是的，经过深入分析，4516+2135=6651。

我看到它早些时候击中了正确的路线。

我很想把这归咎于我与 MULTI 的不健康关系。解决方法很简单，但非确定性调试器听起来很可怕，我想将它运行到地面。有没有人见过 Multi 调试器的行号错误或断点被一个击中？任何人都知道它可能是什么？我搞砸了一些简单的事情吗？

4

1 回答 1

1

我找到了这个。这确实是愚蠢和简单的。

这就是 MULTI 的工作原理。当你设置一个断点时，它会以procedure#123. 123 是从程序开始的偏移量。我拥有的这个可爱的工具是用 ASM 编写的，所以只有一个_start.

MULTI 从 1 开始计算过程行。查看 MULTI 调试器的左侧。这也在帮助文件中“MULTI: Debugging The Source Pane”。最左边的数字列是文件行号。右边的一个是“过程相关的行号”。

所以中断proc#1不是在程序行号+1处中断，而是在程序的第一行中断。这并不是真正的抵消。我不想在 4516+2135 处中断，而是想在 4516 + 第 2136 条指令处中断。我不知道b _start#0会怎么做。

还有一个重要的教训是在填写错误报告和在这里提问时不要偷懒。在上面我输入了行号，但省略了程序号，认为它们并不重要。

于 2017-04-14T16:02:45.567 回答