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

[Rui Ueyama via llvm-dev]

On Fri, Jun 3, 2016 at 2:28 AM, Peter Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>

Simon implemented "thunk" for MIPS. Thunk contains linker-generated machine
code and is added after each input section in the result and bridges
incompatible function calls. I think you can use it for ARM thumb and
non-thumb function calls.


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

I think we already have a good foundation, so I guess you only need add
architecture-specific code there in Relocations.cpp.

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


Is there anything special in them from the linker's perspective?

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.
>

This can be added to thunks, I guess.


> 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.
>

Does this mean you need to read every 4 bytes in .text (or 2 bytes if
thumb) and swap the byte order of the word, if the target is big-endian? If
the linker is supposed to do it, we have no choice other than doing it, but
it's... weird.

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

You may want to take a look at isCompatible function in SymbolTable.cpp
which does similar thing.

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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160603/63161cfb/attachment.html>