[PATCH] D66426: [lld] Enable a watermark of loadable sections to be generated and placed in a note section

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 21 04:47:11 PDT 2019


MaskRay added a comment.

In D66426#1639069 <https://reviews.llvm.org/D66426#1639069>, @davidb wrote:

> In D66426#1639065 <https://reviews.llvm.org/D66426#1639065>, @davidb wrote:
>
> > In D66426#1637540 <https://reviews.llvm.org/D66426#1637540>, @MaskRay wrote:
> >
> > > Another problem is that .note.gnu.build-id is SHF_ALLOC and included in a PT_LOAD segment. When computing watermark, you probably don't want to include its contents. So you should compute build-id and watermark first before you write.
> >
> >
> > What target are you looking at? I thought generally note sections aren't allocated and are usually safe to remove. If they were included in a segment, then that would be a PT_NOTE segment that isn't nested in a PT_LOAD segment.
>
>
> Actually nevermind. I've just found a few example of scripts placing the build-id into text so the value can be accessed at runtime.


Unless you mark a SHF_ALLOC output section as NOLOAD or discard it, it should be included in at least one PT_LOAD segment. ELF spec says: "SHF_ALLOC - The section occupies memory during process execution."
SHT_NOTE sections are usually SHF_ALLOC. This is because 1) many are inspected at runtime 2) many are expected to be dumped to core (this applies to .note.ABI-tag .note.gnu.build-id .note.tag ...). Non-SHF_ALLOC SHT_NOTE section exist in the wild, but they are rare, e.g. GHC uses `.debug-ghc-link-info` (`compiler/main/SysTools/ExtraObj.hs`). The computation of .note.llvm.watermark cannot depend on the contents of .note.gnu.build-id so I suggested computing both before writing the contents.

I hope some of you can answer my motivation/justification question above. Whether or not this change is justified to be made into LLD, I think you'll need a llvm-readobj change to dump the note. Also, as I noted above, the llvm-readobj change will help testing the linker feature. You can add the `include/llvm/BinaryFormat/ELF.h` change to that llvm-readobj patch.


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

https://reviews.llvm.org/D66426





More information about the llvm-commits mailing list