[PATCH] D103815: [LLD][ELF] Fix PT_LOAD program header creation for NO_LOAD sections

Konstantin Schwarz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 14 03:36:39 PDT 2021


kschwarz added inline comments.


================
Comment at: lld/test/ELF/linkerscript/noload.s:13
 # CHECK:      Type Offset   VirtAddr           PhysAddr
+# CHECK-NEXT: LOAD 0x001000 0x0000000000000000 0x0000000000000000
 # CHECK-NEXT: LOAD 0x001000 0x0000000000020000 0x0000000000020000
----------------
MaskRay wrote:
> kschwarz wrote:
> > GNU ld creates the following program headers:
> > 
> > ```
> >   LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x001000 RW  0x1000
> >   LOAD           0x000000 0x0000000000010000 0x0000000000010000 0x000000 0x001001 RW  0x1000
> >   LOAD           0x001000 0x0000000000020000 0x0000000000020000 0x000001 0x000001 R E 0x1000
> > ```
> > 
> > Should we create a new header whenever a section has an `addrExpr` set, similar to our condition for lmaExpr?
> > 
> > GNU ld will only create a new header if the current section is placed at a discontiguous address.
> Try merging PT_LOAD with same flags and contiguous address ranges.
> 
> Doing this rigidly can make the code more complex. In such cases we may trade the merged behavior for simpler implementation.
I had a look when/where the merging of PT_LOAD segments with contiguous address ranges should occur.
If no `addrExpr`s are used, the VMAs will usually be contiguous and we can keep the current behavior, i.e. check whether the `memregion`s are identical.

However if `addrExpr`s are used, we cannot know whether two output sections will have contiguous address ranges until after the final layout is fixed. In that case, we would need a final "merge pass", maybe at the same time we remove empty PT_LOAD segments.

If you agree, I'd like to keep these changes separate and first commit this change (creating PT_LOAD headers for NOLOAD sections).

Creating a new PT_LOAD header for every section that uses an `addrExpr` breaks quite some tests in the test suite, so that definitely needs a closer look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103815/new/

https://reviews.llvm.org/D103815



More information about the llvm-commits mailing list