Issue when using the debugger w/ MIPS32 code about miasm

[commial]

In Miasm2, the delay-slot is handled during the creation of IR Blocks, by separating the update of the IRDst variable and its use. This variable indicates where is the next block to execute (in contrary of PC, which can't have labelled values like generated labels).

For instance, if I asm the mips32.S sample:

python asm/shellcode.py mips32b samples/mips32.S babar.bin

And then I gen the associated IR:

python -i disasm/full.py mips32b babar.bin 0

The block named loc_0000000000000008:0x00000008 has the following list of affectation block

A1 = (A1+0x1)

PC = ((A0+(- ZERO))?loc_0000000000000008:0x00000008,loc_0000000000000014:0x00000014))
IRDst = ((A0+(- ZERO))?loc_0000000000000008:0x00000008,loc_0000000000000014:0x00000014))

A0 = (A0+0xFFFFFFFF)

We can observe the block relative to offset 0x10 does not set IRDst, which is evaluated in the context of the offset 0xC.

Now, the way the step work in the debugging feature is implemented in miasm2/analysis/debugging.py, method step:

# Force the jit of one line, and remove the old one
self.myjit.jit.set_options(jit_maxline=1)
self.myjit.jit.updt_automod_code(self.myjit.vm, self.myjit.pc, 8)

# Launch the run (just one line will be jitted and execute)
res = self.myjit.continue_run(step=True)
# Handle the result (exceptions, breakpoints, ...)
self.handle_exception(res)

...

So, currently, lines are considered separately. That's why in run mode, the debugging will work with delay slot, and in the step mode it will not.

I'll get back to you if I found a clean way to handle delay-slot in this case.
Hope I've help you to understand the code you've nightly watched.