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

[Denis Protivensky]

>>! In D6446#25, @shankarke wrote:
> Need some more tests 
> 
> a) TLS
> b) Check the ARM relocations that you have implemented.
> 
> You havent fixed up the exidx_start/end symbol.
> 
> I dont see the defsym test testing pieces of ARM functionality that you have implemented.

Shankar,

Thanks for reviewing this.

The goal of this initial patch is to make a start of ARM ELF generation. The patch doesn't even make static linking possible. All relocation handlres, including TLS handlers, those requiring veneer generation and others come from libc which I'm linking against during manual testing.
I mean that, I can't reproduce these in tests unless making specific samples with TLS variables, or with BL/BLX instructions, and if I start adding them - we end up having not working code in general, with [highly possibly] not working tests, because there's no guarantee that I can implement everything correctly without real testing.

So I propose to add all these things into the TODO list, and also mark them as requiring tests. This is related to TLS handlers, veneers, .exidx section's symbols and others.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMExecutableWriter.h:33-34
@@ +32,4 @@
+  void addDefaultAtoms() override {
+    _armRuntimeFile->addAbsoluteAtom("__exidx_start");
+    _armRuntimeFile->addAbsoluteAtom("__exidx_end");
+
----------------
shankarke wrote:
> I couldnt find any place where this gets fixed up.
It doesn't because my goal is to make the simplest case link statically. I suspect there shouldn't be any exception handling sections, so I decided to drop it for some time. These two atoms needed to make the linker happy and don't break with unresolved symbols error.

I'd prefer adding handling of these later since it at least requires reading exception handling ABI addendum, and maybe writing separate test cases. I noted in the TODO list about the need of .ARM.exidx section handling.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMLinkingContext.h:32-33
@@ +31,4 @@
+  uint64_t getBaseAddress() const override {
+    if (_baseAddress == 0)
+      return 0x400000;
+    return _baseAddress;
----------------
shankarke wrote:
> Is the base address correct for ARM ?
That's a good question. This also was a point of concern to me. Didn't manage to find the answer. Do you know where it may be specified?

================
Comment at: lib/ReaderWriter/ELF/ARM/TODO.rst:8
@@ +7,3 @@
+* Dynamic executable linking
+* DSO linking
+* PLT entries' generation for images larger than 2^28 bytes (see Sec. A.3 of the ELF reference)
----------------
shankarke wrote:
> denis-protivensky wrote:
> > shankarke wrote:
> > > you should also add ARM interoperability.
> > What does that mean? Can you please explain so I understand what I'm adding?
> Sorry I meant ARM interworking here. 
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203j/BCGDIHEC.html
Shankar, thank you for the explanation. Added to the TODO list.

http://reviews.llvm.org/D6446