[PATCH] D85100: [ELF] Allow sections after a non-allocable section to be covered by PT_LOAD

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 4 01:08:48 PDT 2020


jhenderson added a comment.

Somebody else should probably verify that the logic makes sense to them.



================
Comment at: lld/ELF/Writer.cpp:1237
               std::vector<BaseCommand *>::iterator e) {
+  // To make the addresses of orphan sections not affected by non-allocable
+  // sections in the middle, place orphan non-allocable sections in the end.
----------------
MaskRay wrote:
> jhenderson wrote:
> > I think the term is "non-allocatable".
> gABI uses "non-allocable" in one place (SHF_COMPRESSED, contributed by Solaris folks)
> 
> > SHF_COMPRESSED
> >
> > This flag identifies a section containing compressed data. SHF_COMPRESSED applies only to non-allocable sections, and cannot be used in conjunction with SHF_ALLOC. In addition, SHF_COMPRESSED cannot be applied to sections of type SHT_NOBITS.
> 
> I don't find a use of "non-allocatable".
Hmmm... that's an unforutnate word-usage there in the spec. Thinking about it further: SHF_ALLOC is presumably short for some variation of the verb "allocate", whose equivalent adjectives are "allocated" (is assigned memory) and "allocatable" (can be allocated). The opposite of these would actually be "unallocated" (is not assigned memory) and "unallocatable" (cannot be allocated to memory). However, "cannot" is probably too strong a meaning in this context. I don't think "non-alloc[at]able" is really a valid English word.

Maybe we can dodge the issue and just use "non-alloc"? That's what I colloquially use for referring to sections that don't have SHF_ALLOC.


================
Comment at: lld/test/ELF/linkerscript/symbols-non-alloc.test:2-3
 # REQUIRES: x86
+## The address of a symbol assignment after a non-allocable section equals to
+## the end address of the section.
+
----------------
jhenderson wrote:
> 
(Regardless of the non-allocable conversation, the "to" still needs deleting from this comment).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85100



More information about the llvm-commits mailing list