0

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?

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
Philip
  • 1,539
  • 14
  • 23
  • I thought about that one. But it wouldn't explain the change in behavior over lunch same files. Plus I'm seeing the current file hit the wrong place. Unless my math sucks. I dunno, it's something though. I'll try a rebuild. – Philip Mar 09 '17 at 23:37
  • Eh, naw. Rebuild has identical binaries and .ppc files and has the same behavior. – Philip Mar 10 '17 at 16:49
  • Does your script really say "bp", or does it say "b"? At least in MULTI 7, the command is the latter and the former doesn't do anything. – Andres Riofrio Apr 13 '17 at 01:33
  • Ah, you're right. The script is just "b". In the end I'm going to chalk this one up to faulty memory. I know at the time I thought it was changing it's behavior, but it's behaving consistently since I started looking at it. Maybe that hash mark isn't supposed to represent addition? breaking at 6651 yields "prog.ppc"#_start#2136 even though 4516+2136=6652. I guess that's just how it works. ...Wait a minute. OMG. ok, edit incoming. – Philip Apr 14 '17 at 15:27

1 Answers1

1

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.

Philip
  • 1,539
  • 14
  • 23