MIPS汇编中的两个顺序分支指令？

Question

I am trying to reverse engineer a MIPS firmware. The firmware is big endian encoded, for a 32bit r4kec processor.

I have disassembled (using objdump) the binary to see what the assembly looks like, and everything looks like valid code, but right at the beginning of the code I see the following two instructions:

bfc00220    152a0001    bne t1, t2, 0xbfc00228
bfc00224    10000009    b   0xbfc0024c

The first instruction checks the values of the t1 and t2 registers, and jumps to an address if they are not equal. The second instruction seems to handle the fall-through case, to skip directly to a subsequent address. So far so good, or not?

To my knowledge, this is not legal. All of the available MIPS documentation that I have read state that the instruction directly following any branch/jump instruction is treated as a jump delay slot, whose instruction is always (except for the branch-likely class of instructions) executed before the actual jump is performed.

The key problem here is that another branch/jump is not allowed in the jump delay slot, and this will leave the processor in an undefined state.

So what I am to make of this code? I don't believe that this is handcrafted assembly (although it would not be too farfetched for it to be) for a cpu that handles this situation in a known deterministic fashion. I also cannot believe that a compiler will knowingly produce code like this. The other possibility is that I am using the wrong decompiler for the binary, or that I have the endianness wrong, or something else...

Can anyone explain what is going on here?

Answer 1

The "undefined behavior" means just that - that it's not specified what will happen. It may lead to CPU locking up, or it might actually execute the instruction.

See this post about some tricks with delay slots that were used in M88K:

http://www.pagetable.com/?p=313

Or the answer may be even simpler: you may be looking at data, not code. Since a raw binary has no info about code/data boundaries, objdump defaults to disassembling everything, whether it makes sense or not.

Answer 2

While this is undefined behavior, a particular CPU implementation might do something useful and repeatable for this instruction sequence. The only way to tell is by running the code on that actual implementation. Use a debugger to put a breakpoint on the target of each branch, and see which one you get to.

This could even be an error in the hand generated assembly that was never caught because the actual behavior of the code was not incorrect.