[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
Mon Sep 9 20:00:35 PDT 2019


MaskRay added a comment.

This patch introduces a new ELF extension with a new tag: NT_LLVM_WATERMARK. Last times such ELF extensions were made accompanying RFCs were posted:

https://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
https://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html

I still have some concerns about the extension, especially its generality on the widely used ELF platforms.

> We would like to have two PT_NOTEs, one for use by the OS and another for use by tooling. This is achieved by linker scripts. The second PT_NOTE is outside of any PT_LOAD and this is where the watermark would be housed. As described above, a required property of the watermark is that it can be recalculated by an external tool to infer whether or not the loadable parts of the ELF have been modified post-link. By having the watermark outside of any PT_LOAD, it is simpler for the external tool to recalculate. For a similar reason, it would actually be better in our case to have the watermark calculated after the build ID value has been "filled-in", as the build ID is inside a PT_LOAD.

Sorry, I am not following. Do you have a concrete readelf -Sl dump to help my understanding?
By linking a trivial executable with `ld.lld a.o --watermark -o a`, what I see is:

   PHDR           0x000040 0x0000000000200040 0x0000000000200040 0x000118 0x000118 R   0x8
   LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x000174 0x000174 R   0x1000
   GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0
   NOTE           0x000158 0x0000000000200158 0x0000000000200158 0x00001c 0x00001c R   0x4
  
  Section to Segment mapping:
   Segment Sections...
    00
    01     .note.llvm.watermark
    02
    03     .note.llvm.watermark

.note.llvm.watermark is still included in a PT_LOAD segment. I think you probably meant:

- .note.gnu.build-id is included in a PT_LOAD and a PT_NOTE
- .note.llvm.watermark is included in another PT_NOTE

There is also a question why .note.llvm.watermark should be flagged SHF_ALLOC if it is not supposed to be inspected at runtime.



================
Comment at: lld/ELF/InputFiles.cpp:1027
+  // have .build-id sections or watermark, but you can create such files by
+  // "ld.{bfd,gold,lld} -r --build-id/--watermark", and we want to guard against it.
+  if (name == ".note.gnu.build-id" && config->buildId != BuildIdKind::None || name == ".note.llvm.watermark")
----------------
```
% ld.lld -r --watermark a.o -o b.o
ld.lld: error: Unable to apply watermark because no PT_LOAD segments were found!                               
ld.lld: ../projects/lld/ELF/Writer.cpp:2690: void WriteHash(std::vector<uint8_t> &, const size_t, const size_t,
size_t, const lld::elf::BuildIdKind): Assertion `first < last' failed.
```


================
Comment at: lld/ELF/Writer.cpp:2761
+  // by utilities such as objcopy.
+  first = std::max(sizeof(ELFT::Ehdr), first);
+
----------------
error: missing 'typename' prior to dependent type name 'ELFType<llvm::support::big, false>::Ehdr'


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

https://reviews.llvm.org/D66426





More information about the llvm-commits mailing list