[PATCH] [lld][ELF][ARM] Add veneer generation to branch instructions

Denis Protivensky dprotivensky at accesssoftek.com
Tue Feb 10 00:19:14 PST 2015


================
Comment at: lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp:33-113
@@ -32,1 +32,83 @@
 
+// ARM B/BL instructions of static relocation veneer.
+// TODO: consider different instruction set for archs below ARMv5
+// (one as for Thumb may be used though it's less optimal).
+const uint8_t Veneer_ARM_B_BL_StaticAtomContent[8] = {
+    0x04, 0xf0, 0x1f,
+    0xe5,             // ldr pc, [pc, #-4]
+    0x00, 0x00, 0x00,
+    0x00              // <target_symbol_address>
+};
+
+// Thumb B/BL instructions of static relocation veneer.
+// TODO: consider different instruction set for archs above ARMv5
+// (one as for ARM may be used since it's more optimal).
+const uint8_t Veneer_THM_B_BL_StaticAtomContent[8] = {
+    0x78, 0x47,       // bx pc
+    0x00, 0x00,       // nop
+    0xfe, 0xff, 0xff,
+    0xea              // b <target_symbol_address>
+};
+
+/// \brief Atoms that hold veneer code.
+class VeneerAtom : public SimpleELFDefinedAtom {
+  StringRef _section;
+
+public:
+  VeneerAtom(const File &f, StringRef secName)
+      : SimpleELFDefinedAtom(f), _section(secName) {}
+
+  Scope scope() const override { return DefinedAtom::scopeTranslationUnit; }
+
+  SectionChoice sectionChoice() const override {
+    return DefinedAtom::sectionBasedOnContent;
+  }
+
+  StringRef customSectionName() const override { return _section; }
+
+  ContentType contentType() const override {
+    return DefinedAtom::typeCode;
+  }
+
+  uint64_t size() const override { return rawContent().size(); }
+
+  ContentPermissions permissions() const override { return permR_X; }
+
+  Alignment alignment() const override { return Alignment(2); }
+
+#ifndef NDEBUG
+  StringRef name() const override { return _name; }
+  std::string _name;
+#else
+  StringRef name() const override { return ""; }
+#endif
+};
+
+/// \brief Atoms that hold veneer for statically relocated
+/// ARM B/BL instructions.
+class Veneer_ARM_B_BL_StaticAtom : public VeneerAtom {
+public:
+  Veneer_ARM_B_BL_StaticAtom(const File &f, StringRef secName)
+      : VeneerAtom(f, secName) {}
+
+  ArrayRef<uint8_t> rawContent() const override {
+    return llvm::makeArrayRef(Veneer_ARM_B_BL_StaticAtomContent);
+  }
+};
+
+/// \brief Atoms that hold veneer for statically relocated
+/// Thumb B/BL instructions.
+class Veneer_THM_B_BL_StaticAtom : public VeneerAtom {
+public:
+  Veneer_THM_B_BL_StaticAtom(const File &f, StringRef secName)
+      : VeneerAtom(f, secName) {}
+
+  DefinedAtom::CodeModel codeModel() const override {
+    return DefinedAtom::codeARMThumb;
+  }
+
+  ArrayRef<uint8_t> rawContent() const override {
+    return llvm::makeArrayRef(Veneer_THM_B_BL_StaticAtomContent);
+  }
+};
+
----------------
shankarke wrote:
> Can you move this into an anonymous namespace.
Yep, missed that.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp:40
@@ +39,3 @@
+    0x00, 0x00, 0x00,
+    0x00              // <target_symbol_address>
+};
----------------
ruiu wrote:
> The address is four byte right? I'd move this 0x00 and the comment to end of the previous line.
Okay.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp:157
@@ +156,3 @@
+    const auto kindValue = ref.kindValue();
+    if (R_ARM_CALL == kindValue || R_ARM_THM_CALL == kindValue)
+      // TODO: need additional check of arch type as it should be
----------------
wnewton wrote:
> 
> It seems like it might be simpler not to pass R_*_CALL relocations into this function at all then we could remove the handling here and in the switch statement below (but retain a comment about ARMv5).
Will, I'm not sure I understand the idea. I take value of relocation from the reference object, and I cannot but pass it into the function as it's used in couple more places.
If I change comparison here and the switch down the code, I'll need to pass couple of flags into the function: isThumbCode, isCall and maybe more.
Could you please explain your thought in more detail?

http://reviews.llvm.org/D7502

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






More information about the llvm-commits mailing list