[llvm-dev] [RFC][LLD][ARM] Initial ARM port for LLD

[Peter Smith via llvm-dev]

Hello everyone,

The review http://reviews.llvm.org/D20951 implements initial support
for the ARM architecture in LLD. To keep the patch size down, and to
avoid the complexities of interworking between ARM and Thumb,  there
is just enough support for an ARM only Hello World to link and run on
ARM Linux [*].

My main aim is to get this functionality committed as the basis of an
ARM port and would like to know how best to go about this? I wanted to
start the ARM port with enough functionality to execute at least one
simple program, although this still might be too large to face in one
review. I'm happy to split it up into a series of smaller patches with
one relocation, one test file. Alternatively if you think more
functionality is needed, please let me know what I need to complete
for a first commit?

The initial goal for Linaro is ARM Linux support for ARMv7 and AArch32
ARMv8. With interworking, TLS and exceptions support the ARM support
and test coverage should be on a par with the current state of the lld
AArch64 support.

There are several major pieces of work to do for ARM linux:

My rough order of priority on what to work on next:

Support for Thumb, Thumb2 and interworking:
- Thumb relocation directives.
- BL to BLX transformation for function calls between ARM and Thumb.
- Thunk generation for B immediate.
- Keeping track of which parts are ARM/Thumb.

Support for TLS
- Add relocation and relaxation support for standard and descriptor
based models.

Support for C++ exceptions:
- Creation of a PT_ARM_EXIDX program header.
- Support for the SHF_LINK_ORDER (used by .ARM.exidx).

Support for range-extension
- Thumb2 BL range is only 16 Mb, conditional branch range is only 1
Mb. Range extension thunks are likely to be needed for large programs.

Support for big-endian ARM targets
- ARMv6 and above has little-endian instructions and big-endian data.
The input objects for ARM have big-endian instructions so the linker
must endian reverse each instruction.

Use SHT_ARM_ATTRIBUTES sections for compatibility checking
- Detect incompatible objects at link-time rather than risk runtime errors.

At this stage I haven't thought too hard about how best to implement
these. I think that some of these may be disruptive enough to post
design alternatives as RFCs rather than as reviews.

[*] I tested hello world against an old GCC distribution that has ARM
only libraries that do not require interworking:
arm-none-linux-gnueabi-gcc (CodeSourcery Sourcery G++ Lite 2007q1-10)
4.2.0.

Documentation can be found in the ABI for the ARM Architecture, which
is available on ARM's website:
http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html
The official instruction encodings are documented in the ARM
Architecture Reference Manual. This is publically available from ARM
but requires a free registration to download:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html