[PATCH] [Mips64] Add support for MCJIT for MIPS64r2 and MIPS64r6

Vladimir Radosavljevic vladimir.radosavljevic at rt-rk.com
Wed May 20 07:18:17 PDT 2015


REPOSITORY
  rL LLVM

================
Comment at: lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:526-529
@@ +525,6 @@
+  // next type of the same relocation entry.
+  useCalculatedValue = !applyRelocation;
+  applyRelocation = r_type2 == ELF::R_MIPS_NONE;
+  resolveMIPS64Relocation(Section, RE.Offset, Value, r_type, RE.Addend,
+                          RE.SectionID, RE.SymOffset);
+
----------------
dsanders wrote:
> This particular overload of resolveMIPS64Relocation is only called from this function. So if we rename it to evaluateMIPS64Relocation(), stop it applying the reloc, and have it take/return the current calculated value we can use it as per this pseudo-code:
>   int64_t calculatedValue = evaluateMIPS64Relocation(Section, RE.Offset, Value, r_type, RE.Addend, RE.SectionID, RE.SymOffset, calculatedValue);
>   if (r_type2 == ELF::R_MIPS_NONE)
>     applyMIPS64Relocation(Section.Address + RE.Offset, calculatedValue);
> This is neater than passing values in side-channels such as member variables.
My understanding of Mips64 ABI is there can be more relocation entries for the same instruction, so i'm using applyRelocation, useCalculatedValue and calculatedValue as members variables to keep them for the following relocation entry if that's the case.

Mips64 ABI allows us e.g.:
000000000000000c R_MIPS_GPREL16 main
000000000000000c R_MIPS_SUB *ABS*
000000000000000c R_MIPS_HI16 *ABS*

000000000000000c R_MIPS_GPREL16 main
000000000000000c R_MIPS_SUB *ABS*
000000000000000c R_MIPS_HI16 *ABS*

So if this is the case (theoretically), we should use result of r_type3 from the first relocation entry, for r_type in the second relocation entry (in our case we should use calculatedValue).

>From Mips64 ABI:

//Up to three operations may be specified per record, by the fields r_type , r_type2 , and r_type3 . They are applied in that order, and a zero field implies no further operations from this record. (The following record may continue the sequence if it references the same offset.)//


================
Comment at: lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:1670-1671
@@ +1669,4 @@
+      Obj.getPlatformFlags(AbiVariant);
+      if ((AbiVariant & ELF::EF_MIPS_ABI2) ||
+          (AbiVariant & ELF::EF_MIPS_ABI_O32))
+        llvm_unreachable("N32 ABI and O32 ABI are not supported on Mips64");
----------------
dsanders wrote:
> mips64/mips64el and O32 is not an error case, it's valid. Admittedly it doesn't work in LLVM at this point (this is a bug) so maybe including O32 in this error is ok for now. Could you add a comment explaining that.
Should i change triple checks for mips and mipsel to O32 ABI checks and report an error only for N32 ABI?

http://reviews.llvm.org/D9667

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list