[Closed] lcb: PIC support for LCB

[kper]

Both RISCV-64 and Aarch64 require PIC (Position Independent Code) to be executed. So far, this hasn't been something that VADL can support.
Overall, I can summarize when PIC affects three areas: global variables, functions, pseudo instructions and assembly parser.
A good introduction gives https://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/.

Summary

Global Variables

But here is a gentle summary. With None Position Independent Code, the symbols are stored directly into an instruction with relocations. The linker then resolves all relocations at link-time and updates the immediate to store the final address. With PIC, the absolute addresses are stored in a separate ELF section called got (Global Offset Table). The GOT contains the absolute addresses to the symbols. So all the immediates refer to the got address instead of the absolute address.

Functions

Addresses to functions are only known at load-time. So, function calls do not call an absolute address but instead a PLT (Procedure Linkage Table) which resolves the address and then caches it in got.

Pseudo Instructions:

The pseudo instruction LA changes its behavior with PIC. In the Non-PIC version, it calculates symbol - PC while with PIC GOT[symbol] - pc.

Additionally, there are more relocations which have to be supported for PIC e.g. GOT_HI20, PCREL_HI20, PCREL_LO12_I and PCREL_LO12_S.

Implementation

Currently, the relocation in VADL looks like this relocation hi( symbol : Bits<32> ) -> UInt<20> = ( ( symbol + 0x800 as Bits<32> ) >> 12 ) as UInt<20>. With PIC more keywords are required to calculate the address. A list of keywords which need to be supported can be found https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#calculation-symbols here.

Name	Calculation
HI20	S + A
PCREL_HI20	S + A - P
LO12_I or LO12_S	S + P
PCREL_LO12_I or PCREL_LO12_S	S - P
GOT_HI20	G + GOT + A - P

Variable	Description
G	Offset of the symbol into the GOT (Global Offset Table)
GOT	Address of the GOT (Global Offset Table)
A	Addend field in the relocation entry associated with the symbol - so for hi it is 0x800
P	Position of the relocation - PC

Assembler Printer / Assembler Parser

The assembler printer (and assembler parser) needs to support the .option PIC which indicates that the assembly was generated with PIC. Like mentioned below, we need also to support @plt suffixes for function calls.

Some useful links:
https://reviews.llvm.org/D55325

Data Relocations

Compiler

The LCB has to define modifiers for all the defined relocations like hi, lo, pcrel_hi, pcrel_lo, got_hi. These need to be mapped to variant kinds, and then to fixups. Finally, the fixups need to be mapped to relocations. Since VADL is more generic then RISC-V, we cannot assume that there is only one immediate in one instruction. Therefore at some point there is a 1:n relationship. The 1:n is between variant kinds and fixups. Each fixup represents one field in a format that has to be updated.
But how does the compiler choose whether it needs the lo or pcrel_lo relocation?
RISC-V defines multiple pseudo instructions to load addresses e.g. PseudoLGA or PseudoLA. The instruction itself is not chosen by the instruction selection but with custom methods in ISelLowering. The pseudo expansion then lowers the modifier in Emit MO_GOT_HI.

The pseudo instruction LA below defines the loading of an address. The compiler can determine whether the pseudo instruction is an absolute pseudo instruction by checking that only absolute relocations are used. Likewise, a relative pseudo instruction can use relative relocations (which use pc) or got relocations (which use got).

  pseudo instruction LA_NON_PIC( rd: Index, symbol: Bits<32> ) =
  {
      AUIPC { rd = rd, imm = hi( symbol ) }
      ADDI { rd = rd, rs1 = rd, imm = lo( symbol ) }
  }
  assembly LA_NON_PIC = (mnemonic, " ", register(rd), hex( symbol ))

 pseudo instruction LA_PIC( rd: Index, symbol: Bits<32> ) =
  {
      AUIPC { rd = rd, imm = got_hi( symbol ) }
      ADDI { rd = rd, rs1 = rd, imm = pcrel_lo( symbol ) }
  }
  assembly LA_PIC = (mnemonic, " ", register(rd), hex( symbol ))

The patch for supporting the pcrel is defined here https://github.com/lowRISC/riscv-llvm/blob/master/0082-RISCV-Add-support-for-pcrel_lo.patch.

Linker

The extension to the linker is not trivial. As defined in the linked discussion, the calculation is splitted across two methods.

First, the entrypoint is in relocateAlloc.

void RISCV::relocateAlloc(InputSectionBase &sec, uint8_t *buf) const {
  uint64_t secAddr = sec.getOutputSection()->addr;
  if (auto *s = dyn_cast<InputSection>(&sec))
    secAddr += s->outSecOff;
  else if (auto *ehIn = dyn_cast<EhInputSection>(&sec))
    secAddr += ehIn->getParent()->outSecOff;
...
  const ArrayRef<Relocation> relocs = sec.relocs();
  for (size_t i = 0, size = relocs.size(); i != size; ++i) {
    const Relocation &rel = relocs[i];
    uint8_t *loc = buf + rel.offset;
    uint64_t val = sec.getRelocTargetVA(ctx, rel, secAddr + rel.offset);

...
  relocate(...);
}

The getRelocTargetVA method itself calculates the value for the relocation with pc or got for all architectures. While, the relocate function will apply the addendum 0x800 and shifting. This is vastly different then we implemented relocations so far, since we directly generated C++ code from the VADL's relocation specification. From my point of view, it makes sense to split relocations up.

absolute relocation hi( symbol : Bits<32> ) -> UInt<20> = ( ( symbol + 0x800 as Bits<32> ) >> 12 ) as UInt<20>
absolute relocation lo( symbol : Bits<32> ) -> SInt<12> = symbol as SInt<12>

relative relocation pcrel_hi( symbol : Bits<32> ) -> UInt<20> = ( ( ( symbol + 0x800 as Bits<32> ) >> 12 ) ) as UInt<20>
relative relocation pcrel_lo( symbol : Bits<32> ) -> UInt<20> = ( symbol ) as UInt<20>

got relocation got_hi( offset : Bits<32> ) -> UInt<20> =  ( ( ( offset + 0x800 as Bits<32> ) >> 12 ) ) as UInt<20>

Since, they are all the same for all architectures, we do not need the PC and GOT calculation itself. We just keep the addendum calculation and translate it as we did before. The only thing that is left to implement is the mapping from a target specific relocations to a generic LLVM relocation. We already do that and an extension is easy. See RISC-V

Call Relocations

The sections before mentioned only static data relocations. Data relocations are for global variables. However, function calls for absolute addresses (non-pic) work exactly like data relocations and nothing has to be changed. When comes to PIC, data relocations and call relocations differ from each other.

The assembly printer needs an extension to print the suffix @plt. The assembly parser has also to support it. Additionally, LowerCall needs to emit the modifier when it is an external symbol. See here. Finally, we need to map the target specific relocation to a generic LLVM relocation. See RISC-V

Useful links:
https://reviews.llvm.org/D63076

Notes for Aarch64

One of the major differences between RISC-V' and Aarch64's relocations is that Aarch64 focuses on partial writes. Static Relocations.

Name	Explanation
R__MOVW_UABS_G0	Set a MOV[KZ] immediate field to bits [15:0] of X; check that 0 <= X < 2^16
R__MOVW_UABS_G1	Set a MOV[KZ] immediate field to bits [31:16] of X; check that 0 <= X < 2^32
R__MOVW_UABS_G2	Set a MOV[KZ] immediate field to bits [47:32] of X; check that 0 <= X < 2^48
R__MOVW_UABS_G3	Set a MOV[KZ] immediate field to bits [63:48] of X (no overflow check needed)

---

This was presented on 12.03.2025 at the VADL meeting. One of the criticized points is that absolute, relative and got must be reserved as keywords. An alternative would be to use annotation instead and just keep the relocation keyword as the only keyword. @AndreasKrall will think about it.

[Jozott00]

If the relocation calculation for the different types of relocations is really the same for all architectures, I think the solution you proposed with the prefixes absolute, relative, got is pretty good, as it is easy to read and does not increase the complexity of relocation definitions. However, if this isn't the same for all architectures, it is probably too restrictive.

I also like the fact that no additional keyword is required for the pseudo-command overload, but that it is determined from the relocations used!

---

Question: How do you know that the hi relocation is used for HI_20 and lo is used for LO12_I and not vice versa?
How is this currently done?

Slightly off topic: Why are relocation definitions in VADL part of the ISA and not the ABI?
Aren't relocations an ABI thing?
EDIT: I guess because the pseudo instructions have to call relocations.

[kper]

If the relocation calculation for the different types of relocations is really the same for all architectures, I think the solution you proposed with the prefixes absolute, relative, got is pretty good, as it is easy to read and does not increase the complexity of relocation definitions. However, if this isn't the same for all architectures, it is probably too restrictive.

I think it is the same for all architectures.

How do you know that the hi relocation is used for HI_20 and lo is used for LO12_I and not vice versa?
How is this currently done?

The hi is only used by the LUI instruction. Therefore, it only needs to support the 20 bits field. However, lo can be used in an ADDI or LD (and the others) or SD (and the others). Therefore, you need to support both I-formats and S-formats. Since, they have different encodings, the RISC-V compiler/linker needs two relocations. Otherwise, the linker needs a decoder to determine the instruction.
This is one of the benefits when you know exactly the ISA that you're targeting. This is something that we cannot do at the moment because it would require a lot of sophisticated analysis to determine which relocation touches which format and needs a separate relocation. Since we agreed to break the ABI compatibility, the LCB should emit a relocation for every format and immediate where an address can be used.

[kper]

Slightly off topic: Why are relocation definitions in VADL part of the ISA and not the ABI?
Aren't relocations an ABI thing?
EDIT: I guess because the pseudo instructions have to call relocations.

Well the assembly names (= modifiers) like %lo or %hi are part of the ISA. But the actual relocation names are defined in the ELF abi.

[kper]

This was presented on 12.03.2025 at the VADL meeting. One of the criticized points is that absolute, relative and got must be reserved as keywords. An alternative would be to use annotation instead and just keep the relocation keyword as the only keyword. @AndreasKrall will think about it.

@AndreasKrall did you make your mind about this? Can we make new keywords or annotations?

[AndreasKrall]

I checked vadl.ATG. absolute, relative, got and eventually further variants would appear in the grammar after an expression. That means, similar to relocation, they would reduce the name space for identifiers. Therefore, we should implement them as annotation. We should make the most common the default for a relocation if no annotation is used. I also do not like the name got. Would be global another good choice or will there be more variants of global tables (I believe the global address table for the Alpha was different to the LLVM got).

[Jozott00]

Maybe [ global offset ]?

[kper]

(I believe the global address table for the Alpha was different to the LLVM got)

I don't think that has anything to do with LLVM itself. I think these are concepts of ELF. So, I skeptical if it is really different. But I don't know Alpha.

[AndreasKrall]

global offset sounds good for me.