Difference between revisions of "NaplesPU LLD Linker"

From NaplesPU Documentation
Jump to: navigation, search
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
When adding a new target architecture to llvm, some changes are required to the tools located in the llvm/tools folder.
+
LLD is the LLVM proprietary linker. It is based on the GNU linker, and it is compatible to it in terms of arguments accepted. It also fully supports the ''ELF'' generation but also, in a progressive lower percentage, ''PE/COFF'', ''Mach-O'', ''WebAssembly'' and custom linker-scripts.
−
== llvm-objdump ==
+
LLD is built as a set of libraries to join the main idea of the software modular design.
−
This is the llvm object file dumper. The full documentation for llvm-objdump is maintained as a Texinfo manual. If the info and llvm-objdump programs are properly installed, the command
 
−
<code> info llvm-objdump </code> should give you access to the complete manual.
 
  
−
In order to be properly used with the NuPlus architecture the following change is required.
+
The NaplesPU implementation of LLD is made on an ELF-based approach, by adding a new Target class inside lld/ELF/Arch folder. [[NaplesPU.cpp]] contains the ''relocation'' logic and other information needed to support NaplesPU. Each NaplesPU application must be linked together with two additional object files:
  
−
<syntaxhighlight lang="cpp" line='line'>
+
* ''crt0.o'', is the object file resulting of the compilation of the start routine for the custom platform, composed of operations needed to set-up the platform.
−
template <class ELFT>
+
* ''vectors.o'', is the Interrupt Vector Table.
−
static std::error_code getRelocationValueString(const ELFObjectFile<ELFT> *Obj,
+
 
−
                                                const RelocationRef &RelRef,
+
== Relocations ==
−
                                                SmallVectorImpl<char> &Result) {
+
This section explains how the relocations are implemented in NaplesPU. 
−
  ...
+
All relocations are specified in the ''relocateOne'' method implementation. By looking at the target ISA, LLD must check for each instruction type in which an immediate value is specified to verify if it can fit the machine instruction field.
−
  switch (EF.getHeader()->e_machine) {
+
 
−
  ...
+
<syntaxhighlight>
−
  case ELF::EM_NUPLUS:
+
void NaplesPU::relocateOne(uint8_t *Loc, uint32_t Type, uint64_t Val) const {
−
    res = Target;
+
  int64_t Offset;
−
    break;
+
  switch (Type) {
 +
  default:
 +
    fatal("unrecognized reloc " + Twine(Type));
 +
    case R_NUPLUS_ABS32:
 +
    write32le(Loc, Val);
 +
    break;
 +
  case R_NUPLUS_BRANCH:
 +
    //Check Offset for J-Type Instructions
 +
    checkInt(Loc, Val, 18, Type);
 +
    applyNaplesPUReloc<18, 0>(Loc, Type, Val);
 +
    break;
 +
  case R_NUPLUS_PCREL_MEM:
 +
    //Check Offset for M-Type Instructions
 +
    checkInt(Loc, Val, 9, Type);
 +
    applyNaplesPUReloc<9, 3>(Loc, Type, Val);
 +
    break;
 +
  case R_NUPLUS_PCREL_LEA:
 +
    //Check Offset for I-Type Instructions
 +
    checkInt(Loc, Val, 9, Type);
 +
    applyNaplesPUReloc<9, 3>(Loc, Type, Val);
 +
    break;
 +
  case R_NUPLUS_ABS_HIGH_LEA:
 +
    //Check Offset for MOVEI-Type Instructions
 +
    checkInt(Loc, (Val >> 16) & 0xFFFF , 16, Type);
 +
    applyNaplesPUReloc<16, 2>(Loc, Type, (Val >> 16) & 0xFFFF);
 +
    break;
 +
  case R_NUPLUS_ABS_LOW_LEA:
 +
    //Check Offset for MOVEI-Type Instructions
 +
    checkInt(Loc, (Val) & 0xFFFF , 16, Type);
 +
    applyNaplesPUReloc<16, 2>(Loc, Type, (Val) & 0xFFFF);
 +
    break;
 +
  }
 +
}
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== llvm-readobj ==
+
All of these implemented relocations relies on the method ''applyNaplesPURelocation'' that simply writes back the value into the instruction.
−
The llvm-readobj tool displays low-level format-specific information about one or more object files.
+
 
−
In order to be properly used with the NuPlus architecture the following change is required.
+
== Linkerscript ==
 +
 
 +
All memory images generated for NaplesPU must be linked in a proper way. This way is specified by the linkerscript:
  
−
<syntaxhighlight lang="cpp" line='line'>
+
<syntaxhighlight>
−
static const EnumEntry<unsigned> ElfMachineType[] = {
+
stacks_dim = 16K;
−
   ...
+
stacks_base = 0x80000;
−
   ENUM_ENT(EM_NUPLUS,        "EM_NUPLUS")
+
threads_per_core = 0x8;
−
</syntaxhighlight>
+
 
 +
SECTIONS
 +
{
 +
  . = 0x00000380;
 +
  .text.vectors : {
 +
    *vectors.o(.text)
 +
    . = 0x00000400;
 +
  }
 +
 
 +
  .text.start : {
 +
    *crt0.o(.text)
 +
  }
 +
  .text : { *(.text) }
 +
 
 +
   . = 0x00800000;
 +
  .data : { *(.data) }
 +
 
 +
   . = ALIGN(64);
 +
  scratchpad : { *(scratchpad) }
 +
 
 +
  .bss : { *(.bss) }
  
−
== linker ==
+
  .eh_frame : { *(.eh_frame) }
  
−
== elf2hex ==
+
}
 +
</syntaxhighlight>
  
−
==== lldb ====
+
As shown above, the linker script commonly defines where the sections must be placed into the memory. Also, it solves undefined symbols of the start routine, specifying the stack size per-thread, the number of threads and the starting address for the stack frame.
−
TBD
 

Latest revision as of 16:21, 21 June 2019

LLD is the LLVM proprietary linker. It is based on the GNU linker, and it is compatible to it in terms of arguments accepted. It also fully supports the ELF generation but also, in a progressive lower percentage, PE/COFF, Mach-O, WebAssembly and custom linker-scripts. LLD is built as a set of libraries to join the main idea of the software modular design.

The NaplesPU implementation of LLD is made on an ELF-based approach, by adding a new Target class inside lld/ELF/Arch folder. NaplesPU.cpp contains the relocation logic and other information needed to support NaplesPU. Each NaplesPU application must be linked together with two additional object files:

  • crt0.o, is the object file resulting of the compilation of the start routine for the custom platform, composed of operations needed to set-up the platform.
  • vectors.o, is the Interrupt Vector Table.

Relocations

This section explains how the relocations are implemented in NaplesPU. All relocations are specified in the relocateOne method implementation. By looking at the target ISA, LLD must check for each instruction type in which an immediate value is specified to verify if it can fit the machine instruction field. 

void NaplesPU::relocateOne(uint8_t *Loc, uint32_t Type, uint64_t Val) const {
  int64_t Offset;
  switch (Type) {
  default:
    fatal("unrecognized reloc " + Twine(Type));
    case R_NUPLUS_ABS32:
     write32le(Loc, Val);
     break;
   case R_NUPLUS_BRANCH:
     //Check Offset for J-Type Instructions
     checkInt(Loc, Val, 18, Type);
     applyNaplesPUReloc<18, 0>(Loc, Type, Val);
     break;
   case R_NUPLUS_PCREL_MEM:
     //Check Offset for M-Type Instructions
     checkInt(Loc, Val, 9, Type);
     applyNaplesPUReloc<9, 3>(Loc, Type, Val);
     break;
   case R_NUPLUS_PCREL_LEA:
     //Check Offset for I-Type Instructions
     checkInt(Loc, Val, 9, Type);
     applyNaplesPUReloc<9, 3>(Loc, Type, Val);
     break;
   case R_NUPLUS_ABS_HIGH_LEA:
     //Check Offset for MOVEI-Type Instructions
     checkInt(Loc, (Val >> 16) & 0xFFFF , 16, Type);
     applyNaplesPUReloc<16, 2>(Loc, Type, (Val >> 16) & 0xFFFF);
     break;
   case R_NUPLUS_ABS_LOW_LEA:
     //Check Offset for MOVEI-Type Instructions
     checkInt(Loc, (Val) & 0xFFFF , 16, Type);
     applyNaplesPUReloc<16, 2>(Loc, Type, (Val) & 0xFFFF);
     break;
  }
}

All of these implemented relocations relies on the method applyNaplesPURelocation that simply writes back the value into the instruction.

Linkerscript

All memory images generated for NaplesPU must be linked in a proper way. This way is specified by the linkerscript: 

stacks_dim = 16K;
stacks_base = 0x80000;
threads_per_core = 0x8;

SECTIONS
{
  . = 0x00000380;
  .text.vectors : {
    *vectors.o(.text)
    . = 0x00000400;
  }

  .text.start : {
    *crt0.o(.text)
  }
  .text : { *(.text) }

  . = 0x00800000;
  .data : { *(.data) }

  . = ALIGN(64);
  scratchpad : { *(scratchpad) }

  .bss : { *(.bss) }

  .eh_frame : { *(.eh_frame) }

}

As shown above, the linker script commonly defines where the sections must be placed into the memory. Also, it solves undefined symbols of the start routine, specifying the stack size per-thread, the number of threads and the starting address for the stack frame.

Retrieved from "http://www.naplespu.com/doc/index.php?title=NaplesPU_LLD_Linker&oldid=2150"