[PATCH] [ELF]: Initial implementation for ARM static linking

Shankar Kalpathi Easwaran shankarke at gmail.com
Sat Nov 29 12:55:41 PST 2014


As Simon mentioned, This change needs more tests as it includes changes to handle dynamic linking too.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMELFFile.h:103-108
@@ +102,8 @@
+      return readAddend_THM_CALL(ap);
+    case llvm::ELF::R_ARM_CALL:
+    case llvm::ELF::R_ARM_JUMP24:
+      return readAddend_ARM_CALL(ap);
+    case llvm::ELF::R_ARM_THM_MOVW_ABS_NC:
+    case llvm::ELF::R_ARM_THM_MOVT_ABS:
+      return readAddend_THM_MOV(ap);
+    case llvm::ELF::R_ARM_THM_JUMP11:
----------------
atanasyan wrote:
> shankarke wrote:
> > All of the above would need to be done in the relocation  handler. We should not interpret the bits in the Reader, this way the Reader is agnostic to the symbol value.
> > 
> > 
> But the relocation handler does not know about used relocation section format (.rel/.rela) so it cannot decide how and where to read an addendum. So I think it is a good approach to read addendums here, construct `Reference` objects, and call the `Reference::addend()` method further.
I have two concerns (a), (b) :-

a) Doing this in the Reader may not be idempotent (Need to consider cases like partial linking and ELF to yam conversions and back to atoms).
b) We may be losing some data because of the transformation in the Reader too, to preserve what was in the object file.

ELFLinkingContext::isRelaOutputFormat() can be used to figure out if the Target is using Rela/Rel. In addition the Target knows the relocation types that it handles.

http://reviews.llvm.org/D6446






More information about the llvm-commits mailing list