[PATCH] D95198: [ELF] Fix program header alloc when first PT_LOAD is not at lowest VMA

[Patrick Oppenlander via Phabricator via llvm-commits]

pattop added a comment.

Thankyou for taking the time to review and comment.

The key requirement here is the ability to control the placement of program headers.

In my experience this is often encountered when dealing with nommu embedded systems, especially when linking for execute-in-place. In this case it's desirable to have program headers reside in flash without loading them into RAM.

On these systems the address of ROM/RAM cannot be controlled. Often ROM is at a higher address than RAM, and there are even systems with RAM at address 0 (e.g. ITCM on Cortex-M7).

I'm not sure where the requirement comes from that the first load segment must cover the program headers. GNU ld fails with the error "PHDRS and FILEHDR are not supported when prior PT_LOAD headers lack them" if this is not met. I did the same without thinking about whether this is really necessary. Maybe it is simply a limitation of GNU ld?

I have not been able to craft a linkscript for LLD which can place the program headers somewhere other than the lowest VMA in the program. I've had (unpatched) LLD create multi-gigabyte ELF files with overlapping load segments while trying.

To directly address your questions:

> Does this solve a category of linker script problems?

Yes, generally nommu embedded and execute in place use cases.

> Can you adapt your linker script to run with both GNU ld and LLD?

I don't think so. In general GNU ld works without any problems. I haven't come up with a solution which works with LLD without patches.

> If not, do you think there is some exotic part which can be changed without affecting functionality?

I'm not sure, sorry.

> If we don't support such usage, does that affect a large number of users? (Assuming they have willingness to adapt their linker scripts)

I think this certainly limits the usability of LLD in nommu/deeply embedded/XIP scenarios. I can't comment on how many users this may be.

> If we add this, do we still have explainable behaviors?

I don't think there will be any difficulties explaining the behaviours if they are similar enough (or equivalent) to GNU ld.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95198