[ELF] Avoid creating a 2.1GB output file in arm-exidx-range.s

[arichardson]

Summary

Currently both sections will be placed in the same PT_LOAD and therefore
lld generates a contiguous output file containing both sections.
By marking the .vectors section as writable, it will be placed in a
separate PT_LOAD and the resulting file is now only a few kilobytes.

[psmith]

Thanks for spotting that. I'd personally prefer to fix in the linker script, rather than make the code RW but I don't have a strong preference.

In a magical world where there is spare time, it would be great to make the LLD program header generation more like BFD which I believe will generate separate program headers when the distance between OutputSections is large. Not for this patch though.

lld/test/ELF/arm-exidx-range.s

6

This can be also be fixed by replacing this line:
.vectors 0xffff0000 : AT(0xffff0000) : { *(.vectors) } \

[arichardson]

Use linker script approach instead

[arichardson]

This comment has been deleted.

lld/test/ELF/arm-exidx-range.s

6

Thanks, that's a better solution. I thought I'd have to add custom PHDRS to fix this so I used the attribute mismatch to force a new PT_LOAD.

[MaskRay]

In D85661#2207274, @psmith wrote:

Thanks for spotting that. I'd personally prefer to fix in the linker script, rather than make the code RW but I don't have a strong preference.

In a magical world where there is spare time, it would be great to make the LLD program header generation more like BFD which I believe will generate separate program headers when the distance between OutputSections is large. Not for this patch though.

This reminds me of D79254 and a previous discussion about why RISC-V relaxation is difficult to implement in LLD.

BFD does program header allocation and address assignments in a loop while we don't. We could allocate a new header whenever an output section address is specified but that could waste lots of program header space if we ended up merging many PT_LOAD segments. If we have a loop as well, we can indeed behave more like BFD. The additional complexity needs a lot of thoughts.

lld/test/ELF/arm-exidx-range.s

 // REQUIRES: arm
 // RUN: llvm-mc --arm-add-build-attributes --triple=armv7a-linux-gnueabihf -filetype=obj %s -o %t.o
 // RUN: echo "SECTIONS { \
 // RUN:         . = 0x80000000; \
 // RUN:         .text : { *(.text) } \
 // RUN:         .vectors 0xffff0000 : { *(.vectors) } \
 // RUN: } " > %t.script
 // RUN: ld.lld --script %t.script %t.o -o %t
 // RUN: llvm-readobj -x .ARM.exidx %t | FileCheck %s
 /// Adapted from Linux kernel linker script failing due to out of range
 /// relocation. The .vectors at 0xffff0000 is a common occurrence as the vector
 /// table can only be placed at either 0 or 0xffff0000 in older ARM CPUs.
 /// In the example the .vectors won't have an exception table so if LLD creates
 /// one then we'll get a relocation out of range error. Check that we don't
 /// synthesise a table entry or place a sentinel out of range.
 
 /// Expect only .ARM.exidx from _start and sentinel
 // CHECK: Hex dump of section '.ARM.exidx':
 // CHECK-NEXT: 0x80000000 10000000 01000000 0c000000 01000000
 // CHECK-NOT:  0x80000010
 
  .text
  .global _start
  .type _start, %function
 _start:
  .fnstart
  bx lr
  .cantunwind
  .fnend
 
- .section .vectors, "ax", %progbits
+ .section .vectors, "awx", %progbits
  .global vecs
  .type vecs, %function
 vecs:
  bx lr