[PATCH] [Mips] Add support for MCJIT for MIPS32r6

Vladimir Radosavljevic vladimir.radosavljevic at rt-rk.com
Wed Jun 24 07:42:42 PDT 2015


Comment at: lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:1312-1315
@@ -1268,6 +1311,6 @@
     } else {
-      if (RelType == ELF::R_MIPS_HI16)
+      if (RelType == ELF::R_MIPS_HI16 || RelType == ELF::R_MIPS_PCHI16)
         Value.Addend += (Opcode & 0x0000ffff) << 16;
       else if (RelType == ELF::R_MIPS_LO16)
         Value.Addend += (Opcode & 0x0000ffff);
       else if (RelType == ELF::R_MIPS_32)
dsanders wrote:
> I'll need to look up the details of the Mips32r6 relocs to review this patch.
> However, I believe I've noticed a significant bug in the nearby code that I ought to mention. The handling of R_MIPS_HI16 and R_MIPS_LO16 is incorrect. These relocs have the unusual property that their addend is 32-bit with Hi16 and LO16 each contributing 16-bits. This means that to handle a HI16, we must scan forwards to the corresponding LO16 to retrieve the other half of the addend. Similarly, LO16 must scan backwards to find the top half of the addend. We probably have bugs when the addend causes the result to cross a 16-bit boundary since the carry from the LO16 won't propagate into the HI16:
>   foo = 65532
>   R_MIPS_HI16(Symbol = foo, Addend = 0): Value is 65532 >> 16 = 0 (but should be 1)
>   R_MIPS_LO16(Symbol = foo, Addend = 8): Value is 65540 & 0xffff = 4
> @atanasyan: I think you've implemented HI16/LO16 in lld. Is my understanding of this correct?
I can add FIXME in this patch, and a fix for this bug can be part of another patch. What are your thoughts?



More information about the llvm-commits mailing list