relocations(mips): fixed R_MIPS_HI16 and R_MIPS_LO16

[DanielBotnik]

Closes #482

This MR Solves multiple issues in R_MIPS_HI16 and R_MIPS_LO16 relocations.

• Take into consideration the binary endianness, (off by 2 bytes)
• Take into consideration R_MIPS_HI16 sign.
• Take into consideration the pre placed compiler value, that need to be added to the target symbol.

I've also added a test using the binary in the mentioned issue above, which requires the following binaries PR:
angr/binaries#127

[DanielBotnik]

I've seen that my test didnt run, so I changed it to unittest, now it suppose to work.

[DennyDai]

@DanielBotnik Thanks for trying to fix it!

While this is more correct than the existing version, it might still to be wrong for some corner cases.

The information from the documentation is equivalent to

AHL = (AHI << 16) + ALO
R_MIPS_HI16: (AHL + S) >> 16
R_MIPS_LO16: (AHL + S) & 0xFFFF

(AHL is 32 bits, ALO/AHI are 16 bits)

Which we can then simplify to

R_MIPS_HI16: (AHI + ((ALO + S) >> 16))
R_MIPS_LO16: (ALO + S) & 0xFFFF

While we no longer need AHI for LO16 after simplification, we still need ALO for correctly calculating HI16.

Your implementation is equivalent to the following

R_MIPS_HI16: (AHI + (S >> 16)) + (1 if S & 0x8000)

Consider the following case:

S = 0x10
AHI = 0x1
ALO = 0xFFFA

Your implementation: 0x1
Correct result: 0x2

The result will be different in this case.

So if the maintainer decide to merge this PR (because it's still a lot better than existing version and will yield correct result in most cases), I'd prefer to leave the referenced issue #482 open for the corner case.

[DanielBotnik]

@DennyDai can you take another look, I think it should work now :)

[DennyDai]

@DanielBotnik The overall logic looks good to me, thanks!

[twizmwazin]

Thanks again!