`JALR` causes wrong behavior on AsmMachine when `rs1` and `rd` use the same register.

[jjyr]

Describe the bug

The following instruction will cause different behavior on DefaultMachine(rust) and AsmMachine(asm).

   1021a:	00000097          	auipc	ra,0x0
   1021e:	fd4080e7          	jalr	-44(ra) # 0x101ee

Let's focus on the instruction 1021e. We expect this instruction to jump to rs1(which is ra) - 14 and set the pc + 4 to the rd(which is ra) register. The DefaultMachine handles this as expected. But unfortunately, the AsmMachine set the registers in a wrong ordering:

https://github.com/nervosnetwork/ckb-vm/blob/develop/src/machine/asm/execute.S#L441

AsmMachine set rd first, then read from rs1, when the rs1 and rd use the different registers this behavior is correct, but if the rs1 and rd use the same register then the WRITE_RD operation overwrite the value of rs1.

How to fix

To simply fix this problem, we can move the WRITE_RD to the after of the REGISTER_ADDRESS(RS1).

The change may cause the network consensus split. We need to wait for a hard-fork to apply it.

[xxuejie]

First, I've checked that all the system scripts do not have contain code that can trigger this bug, the problem is that gcc would optimize the following code:

   1021a:	00000097          	auipc	ra,0x0
   1021e:	fd4080e7          	jalr	-44(ra) # 0x101ee

into the following one instruction:

   jal ra, 0x101ee

jal won't trigger the above bug, hence the behavior we will observe here is: for programs compiled with gcc, CKB VM can run them perfectly, but for programs compiled via LLVM(it needs to be checked if latest LLVM has already fixed this), this bug might be encountered.

But this optimization is missing at least in the LLVM version used in Rust right now.

A proper fix here will need consensus change, hence we can only wait till the time a hardfork is performed. However, for the moment we can build a separate patcher that applies the transformation above manually, the patched binary will work both right now, and when the proper fix is made.

[xxuejie]

This tool provides a workaround for now that patches RISC-V binary so it won't use the code sequence that is triggering this bug. It can make the code work for now till one of the following conditions are met:

1. This bug is resolved in a future fork
2. The compiler adds linker optimization and stops generating this code sequence

[xxuejie]

ASM & AOT mode fixed in #99
AOT mode will need a separate PR