[ELF][RISCV] Implement --emit-relocs with relaxation

[jobnoorman]

Summary

Linker relaxation may change relocations (offsets and types). However,
when --emit-relocs is used, relocations are simply copied from the input
section causing a mismatch with the corresponding (relaxed) code
section.

This patch fixes this as follows: for non-relocatable RISC-V binaries,
InputSection::copyRelocations reads relocations from the relocated
section's relocations array (since this gets updated by the relaxation
code). For all other cases, relocations are read from the input section
directly as before.

In order to reuse as much code as possible, and to keep the diff small,
the original InputSection::copyRelocations is changed to accept the
relocations as a range of Relocation objects. This means that, in the
general case when reading from the input section, raw relocations need
to be converted to Relocations first, which introduces quite a bit of
boiler plate. It also means there's a slight code size increase due to
the extra instantiations of copyRelocations (for both range types).

[MaskRay]

Nice!

[lld][RISCV] Fix --emit-relocs with relaxation

Sorry for some bikeshedding.
For projects like llvm,clang,lld, I think we omit [lld] unless we do treewide cleanup.
And a more specific tag is probably more common, like [ELF].

I think "Implement" or "Support" is better than "Fix" as we don't claim that --emit-relocs for RISC-V is implemented.
We just don't report an error.

GNU ld changes R_RISCV_RELAX to R_RISCV_NONE. I think keeping R_RISCV_RELAX is better. Projects depending on the relocation type should be aware.

lld/ELF/InputSection.cpp

364

indicate nonnull-ness

lld/test/ELF/riscv-relax-emit-relocs.s

14

We need --no-relax tests.

40

Add alignment directives to create R_RISCV_ALIGN

[jobnoorman]

Address @MaskRay's comments:

• Make MapRel::file a reference;
• Add tests for --no-relax (and make sure it works because it didn't before);
• Add tests for R_RISCV_ALIGN;
• Update title.

[jobnoorman]

In D159082#4635795, @MaskRay wrote:

GNU ld changes R_RISCV_RELAX to R_RISCV_NONE. I think keeping R_RISCV_RELAX is better. Projects depending on the relocation type should be aware.

GNU ld seems to keep R_RISCV_RELAX but changes R_RISCV_ALIGN to R_RISCV_NONE:

$ riscv64-linux-gnu-gcc -nostdlib -Wl,--emit-relocs,-Ttext=0x10000 lld/test/ELF/riscv-relax-emit-relocs.s
$ riscv64-linux-gnu-objdump -dr a.out

a.out:     file format elf64-littleriscv


Disassembly of section .text:

0000000000010000 <_start>:
   10000:	008000ef          	jal	ra,10008 <f>
			10000: R_RISCV_JAL	f
			10000: R_RISCV_RELAX	*ABS*
   10004:	004000ef          	jal	ra,10008 <f>
			10004: R_RISCV_JAL	f
			10004: R_RISCV_RELAX	*ABS*

0000000000010008 <f>:
   10008:	8082                	ret
			10008: R_RISCV_NONE	*ABS*+0x6

I can see the logic of removing R_RISCV_ALIGN since it doesn't make too much sense anymore once the padding nops are removed. Do you think we should follow this behavior? The current version of the patch keeps it which at least allows analysis tools to recover the original alignment requirements.

[jrtc27]

In D159082#4636067, @jobnoorman wrote:

In D159082#4635795, @MaskRay wrote:

GNU ld changes R_RISCV_RELAX to R_RISCV_NONE. I think keeping R_RISCV_RELAX is better. Projects depending on the relocation type should be aware.

GNU ld seems to keep R_RISCV_RELAX but changes R_RISCV_ALIGN to R_RISCV_NONE:

$ riscv64-linux-gnu-gcc -nostdlib -Wl,--emit-relocs,-Ttext=0x10000 lld/test/ELF/riscv-relax-emit-relocs.s
$ riscv64-linux-gnu-objdump -dr a.out

a.out:     file format elf64-littleriscv


Disassembly of section .text:

0000000000010000 <_start>:
   10000:	008000ef          	jal	ra,10008 <f>
			10000: R_RISCV_JAL	f
			10000: R_RISCV_RELAX	*ABS*
   10004:	004000ef          	jal	ra,10008 <f>
			10004: R_RISCV_JAL	f
			10004: R_RISCV_RELAX	*ABS*

0000000000010008 <f>:
   10008:	8082                	ret
			10008: R_RISCV_NONE	*ABS*+0x6

I can see the logic of removing R_RISCV_ALIGN since it doesn't make too much sense anymore once the padding nops are removed. Do you think we should follow this behavior? The current version of the patch keeps it which at least allows analysis tools to recover the original alignment requirements.

They would be invalid though:

The addend indicates the number of bytes occupied by nop instructions at the relocation offset. The alignment boundary is specified by the addend rounded up to the next power of two.

[jrtc27]

lld/ELF/InputSection.cpp

355

Isn’t that true of other architectures though? TLS relaxations, GOT->PCREL relaxation, …

[jobnoorman]

Emit R_RISCV_NONE instead of R_RISCV_ALIGN since the latter would be invalid
once padding nops are removed. This is also consistent with the behavior of GNU
ld.

Note that I set the addend of R_RISCV_NONE to zero since the addend doesn't have
any meaning here. However, this is not consistent with GNU ld, which has an
addend but its value is a bit mysterious to me (it's not the same as the
original R_RISCV_ALIGN).

Note that I would have liked to be able to implement this in RISC-V specific
code (e.g., in riscvFinalizeRelax). This proved problematic, however, since
with --no-relax, R_RISCV_RELAX relocations will not be added to
InputSectionBase::relocations. Since we still want to emit those relocations,
copyRelocations cannot use the relocations array when --no-relax is used but
instead has to copy them directly from the input section. Therefore, I ended up
changing R_RISCV_ALIGN to R_RISCV_NONE inside copyRelocations.

[MaskRay]

I think I like R_RISCV_ALIGN better as it is simpler and conveys more information.
Changing to R_RISCV_NONE may not be necessarily their intention. It's just a default behavior in GNU ld when a relocation is nullified.

Ultimately, I think a user processing these relocations need to know these relocations cannot be applied again.

--emit-relocs copied relocations do not have the SHF_ALLOC flag, so they are easily recognizable.

[jobnoorman]

In D159082#4638968, @MaskRay wrote:

I think I like R_RISCV_ALIGN better as it is simpler and conveys more information.
Changing to R_RISCV_NONE may not be necessarily their intention. It's just a default behavior in GNU ld when a relocation is nullified.

Ultimately, I think a user processing these relocations need to know these relocations cannot be applied again.

--emit-relocs copied relocations do not have the SHF_ALLOC flag, so they are easily recognizable.

I think I agree: since the output of --emit-relocs is not supposed to be processed by linkers, there doesn't seem to be a need to follow the psABI to the letter. In fact, we might not be doing that anyway: relocation pairs like R_RISCV_JAL+R_RISCV_RELAX are not defined as valid relaxations but can be produced by --emit-relocs --relax.

I will revert the patch to the previous version. Do you agree @jrtc27?

[jrtc27]

I think it's still a bit dodgy for R_RISCV_ALIGN specifically, and don't like the divergence from GNU ld -- there should really be consensus between the toolchains there -- but it may be ok.

Regarding R_RISCV_RELAX pairs that don't normally exist: nothing in the psABI says you can't do that, they just don't have a defined meaning, and in fact that's a good thing, because it means new relaxations can be defined in future and toolchains can unconditionally emit them without having to worry about whether or not the linker knows about them; old linkers will just treat them as if they didn't have R_RISCV_RELAX.

[jobnoorman]

In D159082#4639290, @jrtc27 wrote:

I think it's still a bit dodgy for R_RISCV_ALIGN specifically, and don't like the divergence from GNU ld -- there should really be consensus between the toolchains there -- but it may be ok.

I definitely see the point here as well, especially about toolchain consensus.

While trying to figure out whether GNU ld's treatment of R_RISCV_ALIGN is intentional, I noticed that the behavior of --emit-relocs --relax has changed quite a bit since 2.40 (more specifically, since this commit). Since then, most R_RISCV_RELAX relocations are also changed to R_RISCV_NONE. This is the output of GNU ld 2.41 on the test case in this patch:

$ riscv64-linux-gnu-gcc -c llvm-project/lld/test/ELF/riscv-relax-emit-relocs.s
$ binutils-gdb/build/ld/ld-new -q -Ttext=0 riscv-relax-emit-relocs.o
$ riscv64-linux-gnu-objdump -dr a.out

a.out:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <_start>:
   0:	008000ef          	jal	ra,8 <f>
			0: R_RISCV_JAL	f
   4:	004000ef          	jal	ra,8 <f>
			4: R_RISCV_NONE	*ABS*+0x4
			4: R_RISCV_JAL	f

0000000000000008 <f>:
   8:	8082                	ret
			8: R_RISCV_NONE	*ABS*+0x4
			8: R_RISCV_NONE	*ABS*+0x6

I have the feeling this behavior is not intentional at all but rather an artifact of the implementation of relaxation (metadata about necessary code deletion is encoded in relocations which are later overwritten with R_RISCV_NONE).

Given the behavior of the two toolchains has diverged, I think it would make sense to sync with the GNU devs to agree on what the behavior should be. I will start with either opening a bug report or proposing a patch for GNU binutils tomorrow.

[MaskRay]

In D159082#4641158, @jobnoorman wrote:

In D159082#4639290, @jrtc27 wrote:

I think it's still a bit dodgy for R_RISCV_ALIGN specifically, and don't like the divergence from GNU ld -- there should really be consensus between the toolchains there -- but it may be ok.

I definitely see the point here as well, especially about toolchain consensus.

While trying to figure out whether GNU ld's treatment of R_RISCV_ALIGN is intentional, I noticed that the behavior of --emit-relocs --relax has changed quite a bit since 2.40 (more specifically, since this commit). Since then, most R_RISCV_RELAX relocations are also changed to R_RISCV_NONE. This is the output of GNU ld 2.41 on the test case in this patch:

$ riscv64-linux-gnu-gcc -c llvm-project/lld/test/ELF/riscv-relax-emit-relocs.s
$ binutils-gdb/build/ld/ld-new -q -Ttext=0 riscv-relax-emit-relocs.o
$ riscv64-linux-gnu-objdump -dr a.out

a.out:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <_start>:
   0:	008000ef          	jal	ra,8 <f>
			0: R_RISCV_JAL	f
   4:	004000ef          	jal	ra,8 <f>
			4: R_RISCV_NONE	*ABS*+0x4
			4: R_RISCV_JAL	f

0000000000000008 <f>:
   8:	8082                	ret
			8: R_RISCV_NONE	*ABS*+0x4
			8: R_RISCV_NONE	*ABS*+0x6

I have the feeling this behavior is not intentional at all but rather an artifact of the implementation of relaxation (metadata about necessary code deletion is encoded in relocations which are later overwritten with R_RISCV_NONE).

Given the behavior of the two toolchains has diverged, I think it would make sense to sync with the GNU devs to agree on what the behavior should be. I will start with either opening a bug report or proposing a patch for GNU binutils tomorrow.

Opening an https://sourceware.org/ issue is useful but I do believe R_RISCV_RELAX=>R_RISCV_NONE on our side is unnecessary.

--emit-relocs is a debug or advanced feature. Giving more information by preserving the original type has some value. The R_RISCV_RELAX=>R_RISCV_NONE write is unneeded complexity, albeit small.

[MaskRay]

lld/ELF/InputSection.cpp

355

Perhaps Cause and Effect should not be used here. I.e. remove "so", and just state what we do.

[jobnoorman]

• Revert to emitting R_RISCV_ALIGN instead of R_RISCV_NONE;
• Improve comment.

[jobnoorman]

In D159082#4641491, @MaskRay wrote:

Opening an https://sourceware.org/ issue is useful but I do believe R_RISCV_RELAX=>R_RISCV_NONE on our side is unnecessary.

Agreed.

--emit-relocs is a debug or advanced feature. Giving more information by preserving the original type has some value. The R_RISCV_RELAX=>R_RISCV_NONE write is unneeded complexity, albeit small.

I assume you meant R_RISCV_ALIGN => R_RISCV_NONE here? I've reverted the patch to its former behavior (emitting R_RISCV_ALIGN) in any case.

lld/ELF/InputSection.cpp

355

Updated, is this what you had in mind?

[MaskRay]

In D159082#4641639, @jobnoorman wrote:

In D159082#4641491, @MaskRay wrote:

Opening an https://sourceware.org/ issue is useful but I do believe R_RISCV_RELAX=>R_RISCV_NONE on our side is unnecessary.

Agreed.

--emit-relocs is a debug or advanced feature. Giving more information by preserving the original type has some value. The R_RISCV_RELAX=>R_RISCV_NONE write is unneeded complexity, albeit small.

I assume you meant R_RISCV_ALIGN => R_RISCV_NONE here? I've reverted the patch to its former behavior (emitting R_RISCV_ALIGN) in any case.

I filed https://sourceware.org/bugzilla/show_bug.cgi?id=30844 (ld riscv: --emit-relocs does not retain the original relocation type).
I am quite concerned if RISC-V --emit-relocs get more uses before we have figured out the issues.
Please consider that the current lld behavior is highly experimental and don't rely on the behavior in some components like bolt/ (or consider its code highly experimental and may break any time).

[jobnoorman]

In D159082#4644729, @MaskRay wrote:

I filed https://sourceware.org/bugzilla/show_bug.cgi?id=30844 (ld riscv: --emit-relocs does not retain the original relocation type).

Thanks for that! Still waiting for my Sourceware account :/

I am quite concerned if RISC-V --emit-relocs get more uses before we have figured out the issues.
Please consider that the current lld behavior is highly experimental and don't rely on the behavior in some components like bolt/ (or consider its code highly experimental and may break any time).

Yes, will keep this in mind.

lld/ELF/InputSection.h

public:
   uint32_t eqClass[2] = {0, 0};
 
   // Called by ICF to merge two input sections.
   void replace(InputSection *other);
 
   static InputSection discarded;
 
 private:
-  template <class ELFT, class RelTy>
-  void copyRelocations(uint8_t *buf, llvm::ArrayRef<RelTy> rels);
+  template <class ELFT, class RelTy> void copyRelocations(uint8_t *buf);
+
+  template <class ELFT, class RelTy, class RelIt>
+  void copyRelocations(uint8_t *buf, llvm::iterator_range<RelIt> rels);
 
   template <class ELFT> void copyShtGroup(uint8_t *buf);
 };
 
 static_assert(sizeof(InputSection) <= 160, "InputSection is too big");
 
 class SyntheticSection : public InputSection {
 public:

lld/ELF/InputSection.cpp

 
 InputSectionBase *InputSection::getRelocatedSection() const {
   if (!file || (type != SHT_RELA && type != SHT_REL))
     return nullptr;
   ArrayRef<InputSectionBase *> sections = file->getSections();
   return sections[info];
 }
 
+template <class ELFT, class RelTy>
+void InputSection::copyRelocations(uint8_t *buf) {
+  if (config->relax && !config->relocatable && config->emachine == EM_RISCV) {
+    // On RISC-V, relaxation might change relocations so we cannot simply copy
+    // from the input section.
+    InputSectionBase *sec = getRelocatedSection();
+    copyRelocations<ELFT, RelTy>(buf, llvm::make_range(sec->relocations.begin(),
+                                                       sec->relocations.end()));
+  } else {
+    // Convert the raw relocations in the input section into Relocation objects
+    // suitable to be used by copyRelocations below.
+    struct MapRel {
+      const ObjFile<ELFT> &file;
+      Relocation operator()(const RelTy &rel) const {
+        // RelExpr is not used so set to a dummy value.
+        return Relocation{R_NONE, rel.getType(config->isMips64EL), rel.r_offset,
+                          getAddend<ELFT>(rel), &file.getRelocTargetSym(rel)};
+      }
+    };
+
+    using RawRels = ArrayRef<RelTy>;
+    using MapRelIter =
+        llvm::mapped_iterator<typename RawRels::iterator, MapRel>;
+    auto mapRel = MapRel{*getFile<ELFT>()};
+    RawRels rawRels = getDataAs<RelTy>();
+    auto rels = llvm::make_range(MapRelIter(rawRels.begin(), mapRel),
+                                 MapRelIter(rawRels.end(), mapRel));
+    copyRelocations<ELFT, RelTy>(buf, rels);
+  }
+}
+
 // This is used for -r and --emit-relocs. We can't use memcpy to copy
 // relocations because we need to update symbol table offset and section index
 // for each relocation. So we copy relocations one by one.
-template <class ELFT, class RelTy>
-void InputSection::copyRelocations(uint8_t *buf, ArrayRef<RelTy> rels) {
+template <class ELFT, class RelTy, class RelIt>
+void InputSection::copyRelocations(uint8_t *buf,
+                                   llvm::iterator_range<RelIt> rels) {
   const TargetInfo &target = *elf::target;
   InputSectionBase *sec = getRelocatedSection();
   (void)sec->contentMaybeDecompress(); // uncompress if needed
 
-  for (const RelTy &rel : rels) {
-    RelType type = rel.getType(config->isMips64EL);
+  for (const Relocation &rel : rels) {
+    RelType type = rel.type;
     const ObjFile<ELFT> *file = getFile<ELFT>();
-    Symbol &sym = file->getRelocTargetSym(rel);
+    Symbol &sym = *rel.sym;
 
     auto *p = reinterpret_cast<typename ELFT::Rela *>(buf);
     buf += sizeof(RelTy);
 
     if (RelTy::IsRela)
-      p->r_addend = getAddend<ELFT>(rel);
+      p->r_addend = rel.addend;
 
     // Output section VA is zero for -r, so r_offset is an offset within the
     // section, but for --emit-relocs it is a virtual address.
-    p->r_offset = sec->getVA(rel.r_offset);
+    p->r_offset = sec->getVA(rel.offset);
     p->setSymbolAndType(in.symTab->getSymbolIndex(&sym), type,
                         config->isMips64EL);
 
     if (sym.type == STT_SECTION) {
       // We combine multiple section symbols into only one per
       // section. This means we have to update the addend. That is
       // trivial for Elf_Rela, but for Elf_Rel we have to write to the
       // section data. We do that by adding to the Relocation vector.
if (sym.type == STT_SECTION) {
         continue;
       }
       SectionBase *section = d->section;
       if (!section->isLive()) {
         p->setSymbolAndType(0, 0, false);
         continue;
       }
 
-      int64_t addend = getAddend<ELFT>(rel);
-      const uint8_t *bufLoc = sec->content().begin() + rel.r_offset;
+      int64_t addend = rel.addend;
+      const uint8_t *bufLoc = sec->content().begin() + rel.offset;
       if (!RelTy::IsRela)
         addend = target.getImplicitAddend(bufLoc, type);
 
       if (config->emachine == EM_MIPS &&
           target.getRelExpr(type, sym, bufLoc) == R_MIPS_GOTREL) {
         // Some MIPS relocations depend on "gp" value. By default,
         // this value has 0x7ff0 offset from a .got section. But
         // relocatable files produced by a compiler or a linker
         // might redefine this default value and we must use it
         // for a calculation of the relocation result. When we
         // generate EXE or DSO it's trivial. Generating a relocatable
         // output is more difficult case because the linker does
         // not calculate relocations in this mode and loses
         // individual "gp" values used by each input object file.
         // As a workaround we add the "gp" value to the relocation
         // addend and save it back to the file.
         addend += sec->getFile<ELFT>()->mipsGp0;
       }
 
       if (RelTy::IsRela)
         p->r_addend = sym.getVA(addend) - section->getOutputSection()->addr;
       else if (config->relocatable && type != target.noneRel)
-        sec->addReloc({R_ABS, type, rel.r_offset, addend, &sym});
+        sec->addReloc({R_ABS, type, rel.offset, addend, &sym});
     } else if (config->emachine == EM_PPC && type == R_PPC_PLTREL24 &&
                p->r_addend >= 0x8000 && sec->file->ppc32Got2) {
       // Similar to R_MIPS_GPREL{16,32}. If the addend of R_PPC_PLTREL24
       // indicates that r30 is relative to the input section .got2
       // (r_addend>=0x8000), after linking, r30 should be relative to the output
       // section .got2 . To compensate for the shift, adjust r_addend by
       // ppc32Got->outSecOff.
       p->r_addend += sec->file->ppc32Got2->outSecOff;
+    } else if (config->emachine == EM_RISCV && !config->relocatable &&
+               type == R_RISCV_ALIGN) {
+      // Don't emit R_RISCV_ALIGN since it will be invalid once the padding nops
+      // are removed.
+      p->setType(R_RISCV_NONE, /*IsMips64EL*/ false);
+      p->r_addend = 0;
     }
   }
 }
 
 // The ARM and AArch64 ABI handle pc-relative relocations to undefined weak
 // references specially. The general rule is that the value of the symbol in
 // this context is the address of the place P. A further special case is that
 // branch relocations to an undefined weak reference resolve to the next

 }
 
 template <class ELFT> void InputSection::writeTo(uint8_t *buf) {
   if (LLVM_UNLIKELY(type == SHT_NOBITS))
     return;
   // If -r or --emit-relocs is given, then an InputSection
   // may be a relocation section.
   if (LLVM_UNLIKELY(type == SHT_RELA)) {
-    copyRelocations<ELFT>(buf, getDataAs<typename ELFT::Rela>());
+    copyRelocations<ELFT, typename ELFT::Rela>(buf);
     return;
   }
   if (LLVM_UNLIKELY(type == SHT_REL)) {
-    copyRelocations<ELFT>(buf, getDataAs<typename ELFT::Rel>());
+    copyRelocations<ELFT, typename ELFT::Rel>(buf);
     return;
   }
 
   // If -r is given, we may have a SHT_GROUP section.
   if (LLVM_UNLIKELY(type == SHT_GROUP)) {
     copyShtGroup<ELFT>(buf);
     return;
   }

lld/test/ELF/riscv-relax-emit-relocs.s

+# REQUIRES: riscv
+## Test that we can handle --emit-relocs while relaxing.
+
+# RUN: rm -rf %t && mkdir %t && cd %t
+
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+relax %s -o 32.o
+# RUN: ld.lld -Ttext=0x10000 --emit-relocs 32.o -o 32
+# RUN: llvm-objdump -dr --no-show-raw-insn -M no-aliases 32 | FileCheck %s
+
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+relax %s -o 64.o
+# RUN: ld.lld -Ttext=0x10000 --emit-relocs 64.o -o 64
+# RUN: llvm-objdump -dr --no-show-raw-insn -M no-aliases 64 | FileCheck %s
+
+## -r should keep original relocations.
+# RUN: ld.lld -r 64.o -o 64.r
+# RUN: llvm-objdump -dr --no-show-raw-insn -M no-aliases 64.r | FileCheck %s --check-prefix=CHECKR
+
+## --no-relax should keep original relocations.
+# RUN: ld.lld --emit-relocs --no-relax 64.o -o 64.norelax
+# RUN: llvm-objdump -dr --no-show-raw-insn -M no-aliases 64.norelax | FileCheck %s --check-prefix=CHECKNORELAX
+
+# CHECK:      <_start>:
+# CHECK-NEXT:     jal ra, 0x10008 <f>
+# CHECK-NEXT:         R_RISCV_JAL f
+# CHECK-NEXT:         R_RISCV_RELAX *ABS*
+# CHECK-NEXT:     jal ra, 0x10008 <f>
+# CHECK-NEXT:         R_RISCV_JAL f
+# CHECK-NEXT:         R_RISCV_RELAX *ABS*
+# CHECK-EMPTY:
+# CHECK-NEXT: <f>:
+# CHECK-NEXT:     jalr zero, 0(ra)
+# CHECK-NEXT:         R_RISCV_NONE *ABS*
+
+# CHECKR:      <_start>:
+# CHECKR-NEXT:     auipc ra, 0
+# CHECKR-NEXT:         R_RISCV_CALL_PLT f
+# CHECKR-NEXT:         R_RISCV_RELAX *ABS*
+# CHECKR-NEXT:     jalr ra, 0(ra)
+# CHECKR-NEXT:     auipc ra, 0
+# CHECKR-NEXT:         R_RISCV_CALL_PLT f
+# CHECKR-NEXT:         R_RISCV_RELAX *ABS*
+# CHECKR-NEXT:     jalr ra, 0(ra)
+# CHECKR-NEXT:     addi zero, zero, 0
+# CHECKR-NEXT:         R_RISCV_ALIGN *ABS*+0x4
+# CHECKR-EMPTY:
+# CHECKR-NEXT: <f>:
+# CHECKR-NEXT:     jalr zero, 0(ra)
+
+# CHECKNORELAX:      <_start>:
+# CHECKNORELAX-NEXT:     auipc ra, 0
+# CHECKNORELAX-NEXT:         R_RISCV_CALL_PLT f
+# CHECKNORELAX-NEXT:         R_RISCV_RELAX *ABS*
+# CHECKNORELAX-NEXT:     jalr ra, 16(ra)
+# CHECKNORELAX-NEXT:     auipc ra, 0
+# CHECKNORELAX-NEXT:         R_RISCV_CALL_PLT f
+# CHECKNORELAX-NEXT:         R_RISCV_RELAX *ABS*
+# CHECKNORELAX-NEXT:     jalr ra, 8(ra)
+# CHECKNORELAX-EMPTY:
+# CHECKNORELAX-NEXT: <f>:
+# CHECKNORELAX-NEXT:     jalr zero, 0(ra)
+# CHECKNORELAX-NEXT:         R_RISCV_NONE *ABS*
+
+.global _start
+_start:
+  call f
+  call f
+  .balign 8
+f:
+  ret