llvm dev - Jan 2018 - Adding a new target to 'llvm-lld'

Hi LLVM-Devs,

I am considering switching to using 'llvm-lld' instead of Gnu
'ld' in a future revision of our out-of-tree target, and I am wondering
is there a getting started guide for how to go about extending
'llvm-lld' to support an additional target.

Thanks,

	MartinO

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi LLVM-Devs,
>
> I am considering switching to using 'llvm-lld' instead of Gnu
'ld' in a future revision of our out-of-tree target, and I am wondering
is there a getting started guide for how to go about extending
'llvm-lld' to support an additional target.
I don't believe there is, but the patches from Chih-Mao Chen for
RISC-V support seemed well structured to me, so may be useful to learn
from:
* https://reviews.llvm.org/D39322
* https://reviews.llvm.org/D39323
* https://reviews.llvm.org/D39324

As a side note: if any LLD devs have time to review these patches, it
would be hugely appreciated.

Best,

Alex

Thanks Alex, nothing quite as good as learning by example :-)

	MartinO

-----Original Message-----
From: Alex Bradbury [mailto:asb at lowrisc.org] 
Sent: Thursday, January 25, 2018 3:47 PM
To: ORiordan, Martin <martin.oriordan at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; PkmX <pkmx.tw at
gmail.com>
Subject: Re: [llvm-dev] Adding a new target to 'llvm-lld'

On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Hi LLVM-Devs,
>
> I am considering switching to using 'llvm-lld' instead of Gnu
'ld' in a future revision of our out-of-tree target, and I am wondering
is there a getting started guide for how to go about extending
'llvm-lld' to support an additional target.
I don't believe there is, but the patches from Chih-Mao Chen for RISC-V
support seemed well structured to me, so may be useful to learn
from:
* https://reviews.llvm.org/D39322
* https://reviews.llvm.org/D39323
* https://reviews.llvm.org/D39324

As a side note: if any LLD devs have time to review these patches, it would be
hugely appreciated.

Best,

Alex
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

I'm not aware of a written guide either. In 2016 I did a talk on that
subject at the LLVM Cauldron
(http://llvm.org/devmtg/2016-09/#schedule) although quite a bit has
changed since then so I'm hesitant to recommend it apart from general
principles.

I can't speak for the COFF side as I've only worked on the ELF side of
LLD; my suggestions on where to start:
- Properties of the target that are common to all ELF linkers, such as
how relocation directives work, are defined in sub-classes of
TargetInfo. At present each sub-class is implemented in
Arch/<Target>.cpp/ such as Arch/ARM.cpp.
- The driver will instantiate a Target based on the ELF machine type.

If your target can get something basic working without implementing
custom or advanced features then it is possible to get something up
and running quickly and without many lines of code. For example for
Arm, I was able to pick an Arm state only (no interworking)
dynamically linked (no TLS or GNU_IFUNC support) hello world up and
running by just implementing the PLT sequences and the relocations
that I needed.

What happens next depends on how close your target is to an existing
one, both in how it implements general features like TLS, and whether
it needs custom linker generated content such as Thunks. Further
things to consider are whether the default ELF layout suits your
target.

The parts that needed most modifications for Arm were:
- Relocations.cpp; TLS, GNU_IFUNC often need customisation.
- Writer.cpp ; The overall controller of the layout and address allocation.
- SyntheticSections.cpp ; Where linker generated sections are created.
- Thunks.cpp ; Creation of linker generated trampolines between functions.
- InputSection.cpp ; Support relocation calculations specific to Arm.
I needed to add support for a couple of Arm specific section types to
InputFiles.cpp, but otherwise the generic Elf loading parts of LLD
worked without modification.

Searching for Config->EMachine will give you a good idea where
something custom has had to be put in for one of the targets. Stepping
through run() in Writer.cpp will give you a good idea of what order
LLD does various passes.

Hope this helps and I'll be happy to try and answer any questions.

Peter


On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi LLVM-Devs,
>
> I am considering switching to using 'llvm-lld' instead of Gnu
'ld' in a future revision of our out-of-tree target, and I am wondering
is there a getting started guide for how to go about extending
'llvm-lld' to support an additional target.
>
> Thanks,
>
>         MartinO
>
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the
sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
the
> sender and delete all copies.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks Peter,

Fortunately I am only interested in ELF so COFF won't be important to me.  I
really appreciate your guidance, and offer of assistance with questions I may
have.  I don't think that I will be able to start work on this for another
couple of weeks, and this means that I will be using the v6.0.0 release (I
don't track head).

All the best,

	MartinO

-----Original Message-----
From: Peter Smith [mailto:peter.smith at linaro.org] 
Sent: Thursday, January 25, 2018 5:55 PM
To: ORiordan, Martin <martin.oriordan at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Adding a new target to 'llvm-lld'

I'm not aware of a written guide either. In 2016 I did a talk on that
subject at the LLVM Cauldron
(http://llvm.org/devmtg/2016-09/#schedule) although quite a bit has changed
since then so I'm hesitant to recommend it apart from general principles.

I can't speak for the COFF side as I've only worked on the ELF side of
LLD; my suggestions on where to start:
- Properties of the target that are common to all ELF linkers, such as how
relocation directives work, are defined in sub-classes of TargetInfo. At present
each sub-class is implemented in Arch/<Target>.cpp/ such as Arch/ARM.cpp.
- The driver will instantiate a Target based on the ELF machine type.

If your target can get something basic working without implementing custom or
advanced features then it is possible to get something up and running quickly
and without many lines of code. For example for Arm, I was able to pick an Arm
state only (no interworking) dynamically linked (no TLS or GNU_IFUNC support)
hello world up and running by just implementing the PLT sequences and the
relocations that I needed.

What happens next depends on how close your target is to an existing one, both
in how it implements general features like TLS, and whether it needs custom
linker generated content such as Thunks. Further things to consider are whether
the default ELF layout suits your target.

The parts that needed most modifications for Arm were:
- Relocations.cpp; TLS, GNU_IFUNC often need customisation.
- Writer.cpp ; The overall controller of the layout and address allocation.
- SyntheticSections.cpp ; Where linker generated sections are created.
- Thunks.cpp ; Creation of linker generated trampolines between functions.
- InputSection.cpp ; Support relocation calculations specific to Arm.
I needed to add support for a couple of Arm specific section types to
InputFiles.cpp, but otherwise the generic Elf loading parts of LLD worked
without modification.

Searching for Config->EMachine will give you a good idea where something
custom has had to be put in for one of the targets. Stepping through run() in
Writer.cpp will give you a good idea of what order LLD does various passes.

Hope this helps and I'll be happy to try and answer any questions.

Peter


On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Hi LLVM-Devs,
>
> I am considering switching to using 'llvm-lld' instead of Gnu
'ld' in a future revision of our out-of-tree target, and I am wondering
is there a getting started guide for how to go about extending
'llvm-lld' to support an additional target.
>
> Thanks,
>
>         MartinO
>
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited Registered in Ireland 
> Registered Office: Collinstown Industrial Park, Leixlip, County 
> Kildare Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.