Has anyone ever seen Multi debugger get the line number wrong or have a breakpoint hit off by one?
I've got a MULTI script (scripty.rc) that goes through a process that depends upon hitting a breakpoint at the end of this program. The program completes in one of two loops:
:failure
6648 NOP
6649 b failure ; You are a failure
:complete
6650 NOP
6651 b complete ; Your program worked, rejoice
So I'm supposed to break at 6649 or 6651, print the line for the user, and let them verify everything is hunkydory.
BUT.
It's not breaking at 6651. At least not always. Before lunch while I'm making sure it all works, I saw it hit it just like I want. After lunch, when I'm demoing it with the HW guy, the line it prints out is 6650 NOP. Like what the hell? Really? You betray me the moment I demo you?
I verify the software is the same, and it's not some sneaky commit.
I verify the script is the same. It's not like a different breakpoint is being set.
I do the math with the breakpoint. In the script it's bp _start#2135 and yes, _start is at 4516. And yes, after some in-depth analysis, 4516+2135=6651.
And I saw it hit the right line earlier.
I'm tempted to chalk this one up my unhealthy relationship with MULTI. A workaround is easy, but a non-deterministic debugger sounds terrifying and I'd like to run it to ground. Has anyone ever seen Multi debugger get the line number wrong or have a breakpoint hit off by one? Anyone have any idea of what else it could be? Am I screwing up something simple?
I found this one. It is indeed stupid and simple.
That's just how MULTI works. When you set a set a breakpoint, it records it in the form of procedure#123. The 123 is the offset from the start of the procedure. This lovely tool I have is written in ASM so there's just the one _start.
MULTI counts the procedure lines starting at 1. Take a look at the left side of the MULTI debugger. This is in the help file as well "MULTI: Debugging The Source Pane". The leftmost column of numbers is the file line number. The one on the right is the "procedure-relative line number".
So breaking at proc#1 isn't breaking at the procedure line number +1, it's breaking at the first line in the procedure. That's not really an offset. Instead of breaking at 4516+2135, I wanted to break at 4516 + the 2136th instruction. I don't know what b _start#0 would do.
There's also an important lesson about not being lazy when it comes to filling out bug reports and asking questions here. Up above I typed in the line numbers, but omitted the procedure numbers thinking they weren't important.