[lld][ELF] Provide optional hidden symbols for build ID

[phosek]

Summary

This change introduces a new optional hidden symbols build_id_start
and build_id_end which point at the contents of the .note.gnu.build-id
section (if enabled). This is useful in instrumentation runtimes such as
profile where we want to merge profiles produced by the same module.
build ID can be used to uniquely identify modules but there's no easy
way to access it at runtime from the module itself. The build_id_start
and build_id_end symbols make this possible by providing an access to
the .note.gnu.build-id section content.

[MaskRay]

I think we should be a bit more careful proposing a new reserved symbol (symbol assignment even in the absence of a SECTIONS command) and think whether it will be useful after 5 years.

In FreeBSD, their linker script defines:

.note.gnu.build-id : {
  PROVIDE (__build_id_start = .);
  *(.note.gnu.build-id)
  PROVIDE (__build_id_end = .);
}

We need __build_id_end because the size of .build-id can evolve. While I think sha1 is good enough for many use cases, I can imagine someone may want more bits.

OK, I can imagine there are use cases that an external linker script is not desired. There is another perfect alternative: parse PT_NOTE and extract NT_GNU_BUILD_ID.

lld/test/ELF/build-id.s

9

Don't repeat lld command.

10

llvm-objdump -h output does not match GNU objdump. This has been a headache for many projects. llvm-readelf -S -s is usually a bette replacement.

[mcgrathr]

I think if you provide symbols for the section bounds, they should be __start_note_gnu_build_id and __stop_note_gnu_build_id. But that doesn't seem enough of an improvement over parsing phdrs from __ehdr_start to merit the feature IMHO. Consumers still have to parse (or worse yet, assume) the note headers. What would make things trivial for consumers is a pair of symbols giving exactly the bounds of the *payload*, i.e. just the build ID itself (and presenting its variable size in a simple manner).

[phosek]

I have updated the patch to introduce a pair of __build_id_start and __build_id_end which point at the beginning and the end of the payload so users of these symbols don't need to parse the note headers which simplifies usage.

[MaskRay]

In D76482#2182368, @phosek wrote:

I have updated the patch to introduce a pair of __build_id_start and __build_id_end which point at the beginning and the end of the payload so users of these symbols don't need to parse the note headers which simplifies usage.

@mcgrathr's comment https://reviews.llvm.org/D76482#1934097 has not been addressed. I think you can achieve your goal without any new code:

SECTIONS {
  .note.gnu.build-id : {
    __start_note_gnu_build_id = .;
    *(.note.gnu.build-id)
    __stop_note_gnu_build_id = .;
  }
} INSERT BEFORE .dynsym;

INSERT BEFORE|AFTER is special. They are not considered an external linker script (ld.bfd -T a.x --verbose).

If you still want to go down this route, I hope we can see an attempt to sell this idea on binutils side.

[phosek]

In D76482#2183730, @MaskRay wrote:

In D76482#2182368, @phosek wrote:

I have updated the patch to introduce a pair of __build_id_start and __build_id_end which point at the beginning and the end of the payload so users of these symbols don't need to parse the note headers which simplifies usage.

@mcgrathr's comment https://reviews.llvm.org/D76482#1934097 has not been addressed. I think you can achieve your goal without any new code:

SECTIONS {
  .note.gnu.build-id : {
    __start_note_gnu_build_id = .;
    *(.note.gnu.build-id)
    __stop_note_gnu_build_id = .;
  }
} INSERT BEFORE .dynsym;

INSERT BEFORE|AFTER is special. They are not considered an external linker script (ld.bfd -T a.x --verbose).

If you still want to go down this route, I hope we can see an attempt to sell this idea on binutils side.

In the latest patch __build_id_start and __build_id_end point to the payload, not beginning and end of the section, so users don't have to parse the note header, which is what @mcgrathr mentioned in his comment, or is there something else you have in mind? This is also something you cannot replicate with the linker script, with the linker you can point at the beginning and the end of the section, but not the payload.

[MaskRay]

In D76482#2183773, @phosek wrote:

In D76482#2183730, @MaskRay wrote:

In D76482#2182368, @phosek wrote:

I have updated the patch to introduce a pair of __build_id_start and __build_id_end which point at the beginning and the end of the payload so users of these symbols don't need to parse the note headers which simplifies usage.

@mcgrathr's comment https://reviews.llvm.org/D76482#1934097 has not been addressed. I think you can achieve your goal without any new code:

SECTIONS {
  .note.gnu.build-id : {
    __start_note_gnu_build_id = .;
    *(.note.gnu.build-id)
    __stop_note_gnu_build_id = .;
  }
} INSERT BEFORE .dynsym;

INSERT BEFORE|AFTER is special. They are not considered an external linker script (ld.bfd -T a.x --verbose).

If you still want to go down this route, I hope we can see an attempt to sell this idea on binutils side.

In the latest patch __build_id_start and __build_id_end point to the payload, not beginning and end of the section, so users don't have to parse the note header, which is what @mcgrathr mentioned in his comment, or is there something else you have in mind? This is also something you cannot replicate with the linker script, with the linker you can point at the beginning and the end of the section, but not the payload.

Doesn't my INSERT BEFORE example point the symbols at the beginning and the end of the section? You can use HIDDEN or PROVIDE_HIDDEN if you want them to be hidden.

[phosek]

In D76482#2183791, @MaskRay wrote:

In D76482#2183773, @phosek wrote:

In D76482#2183730, @MaskRay wrote:

In D76482#2182368, @phosek wrote:

I have updated the patch to introduce a pair of __build_id_start and __build_id_end which point at the beginning and the end of the payload so users of these symbols don't need to parse the note headers which simplifies usage.

@mcgrathr's comment https://reviews.llvm.org/D76482#1934097 has not been addressed. I think you can achieve your goal without any new code:

SECTIONS {
  .note.gnu.build-id : {
    __start_note_gnu_build_id = .;
    *(.note.gnu.build-id)
    __stop_note_gnu_build_id = .;
  }
} INSERT BEFORE .dynsym;

INSERT BEFORE|AFTER is special. They are not considered an external linker script (ld.bfd -T a.x --verbose).

If you still want to go down this route, I hope we can see an attempt to sell this idea on binutils side.

In the latest patch __build_id_start and __build_id_end point to the payload, not beginning and end of the section, so users don't have to parse the note header, which is what @mcgrathr mentioned in his comment, or is there something else you have in mind? This is also something you cannot replicate with the linker script, with the linker you can point at the beginning and the end of the section, but not the payload.

Doesn't my INSERT BEFORE example point the symbols at the beginning and the end of the section? You can use HIDDEN or PROVIDE_HIDDEN if you want them to be hidden.

We want the opposite though, we want these symbols to point directly at the payload to avoid having to parse the note header.

[MaskRay]

In D76482#2183792, @phosek wrote:

In the latest patch __build_id_start and __build_id_end point to the payload, not beginning and end of the section, so users don't have to parse the note header, which is what @mcgrathr mentioned in his comment, or is there something else you have in mind? This is also something you cannot replicate with the linker script, with the linker you can point at the beginning and the end of the section, but not the payload.

Doesn't my INSERT BEFORE example point the symbols at the beginning and the end of the section? You can use HIDDEN or PROVIDE_HIDDEN if you want them to be hidden.

We want the opposite though, we want these symbols to point directly at the payload to avoid having to parse the note header.

Is this request a bit too ad-hoc? The header is always 16 bytes (BuildIdSection::headerSize). You can write PROVIDE_HIDDEN(__buildid_start = . + 16);

[mcgrathr]

The proposed solution with an input linker script is a clever kludge, but it's a kludge. There's no way to make that actually general, since there is no particular named section that you can correctly assume is present in all kinds of binaries you might be linking. The kludge could be locally tailored for different cases, but that is even worse. Since the section and layout we're talking about here is entirely synthesized by the linker, it makes a lot more sense to have the linker support convenience features for using that format directly than to require users to build detailed kludges baking in the details of the linker's built-in synthesizing behavior.

[MaskRay]

In D76482#2185833, @mcgrathr wrote:

The proposed solution with an input linker script is a clever kludge, but it's a kludge. There's no way to make that actually general, since there is no particular named section that you can correctly assume is present in all kinds of binaries you might be linking. The kludge could be locally tailored for different cases, but that is even worse. Since the section and layout we're talking about here is entirely synthesized by the linker, it makes a lot more sense to have the linker support convenience features for using that format directly than to require users to build detailed kludges baking in the details of the linker's built-in synthesizing behavior.

This may worth a discussion on binutils. There can be several alternative syntax which may meet your needs.

[phosek]

In D76482#2185903, @MaskRay wrote:

In D76482#2185833, @mcgrathr wrote:

The proposed solution with an input linker script is a clever kludge, but it's a kludge. There's no way to make that actually general, since there is no particular named section that you can correctly assume is present in all kinds of binaries you might be linking. The kludge could be locally tailored for different cases, but that is even worse. Since the section and layout we're talking about here is entirely synthesized by the linker, it makes a lot more sense to have the linker support convenience features for using that format directly than to require users to build detailed kludges baking in the details of the linker's built-in synthesizing behavior.

This may worth a discussion on binutils. There can be several alternative syntax which may meet your needs.

One concrete use case we have is in runtimes. We would like for the runtime to use the build ID as the name of the output file because everything in our infrastructure is based on build ID as a way to uniquely identify modules. These runtimes are typically static libraries that are inserted onto the link line by the driver, e.g. if you set -fprofile-instr-generate driver will automatically put libclang_rt.profile.a onto your link line. With your suggested solution, this is going to fail at link time unless the user manually adds the linker script as link input. We could also ship that linker script with the compiler and modify the driver to always add it for you just like it does for the runtime itself. We would need to repeat this for every runtime like profile, XRay, sanitizers, etc. That seems like a worse solution that this patch and I don't think alternative syntaxes are going to help here, the linker script solution is just inconvenient.

[psmith]

It is a pity that the section name is not a valid C identifier otherwise start_ and stop_ would have been generated automatically.

Although less convenient to the programmer using LLD, using the section bounds at least allows someone to fake the symbols with a simple fragment of linker script, thus permitting deployment of the program on older versions of the linker and not needing custom support in ld.bfd:

.note.gnu.build-id : {
  PROVIDE (__build_id_start = .);
  *(.note.gnu.build-id)
  PROVIDE (__build_id_end = .);
}

From the comments above I guess at least __build_id_start could be set to PROVIDE (__build_id_start = . + 16); but that isn't as intuitive.

One final suggestion if the symbols are going to surround the build id payload is to make that explicit in the name, for example __build_id_payload_start.

[phosek]

D102039 is an example use case for this feature.

lld/ELF/Symbols.h

struct ElfSym {
   static Defined *relaIpltStart;
   static Defined *relaIpltEnd;
 
   // __global_pointer$ for RISC-V.
   static Defined *riscvGlobalPointer;
 
   // _TLS_MODULE_BASE_ on targets that support TLSDESC.
   static Defined *tlsModuleBase;
+
+  // __build_id_start and __build_id_end symbols.
+  static Defined *buildIdStart;
+  static Defined *buildIdEnd;
 };
 
 // A buffer class that is large enough to hold any Symbol-derived
 // object. We allocate memory using this class and instantiate a symbol
 // using the placement new.
 union SymbolUnion {
   alignas(Defined) char a[sizeof(Defined)];
   alignas(CommonSymbol) char b[sizeof(CommonSymbol)];

lld/ELF/Symbols.cpp

 Defined *ElfSym::mipsGp;
 Defined *ElfSym::mipsGpDisp;
 Defined *ElfSym::mipsLocalGp;
 Defined *ElfSym::relaIpltStart;
 Defined *ElfSym::relaIpltEnd;
 Defined *ElfSym::riscvGlobalPointer;
 Defined *ElfSym::tlsModuleBase;
 DenseMap<const Symbol *, const InputFile *> elf::backwardReferences;
+Defined *ElfSym::buildIdStart;
+Defined *ElfSym::buildIdEnd;
 
 static uint64_t getSymVA(const Symbol &sym, int64_t &addend) {
   switch (sym.kind()) {
   case Symbol::DefinedKind: {
     auto &d = cast<Defined>(sym);
     SectionBase *isec = d.section;
 
     // This is an absolute symbol.

lld/ELF/SyntheticSections.h

 public:
   GnuPropertySection();
   void writeTo(uint8_t *buf) override;
   size_t getSize() const override;
 };
 
 // .note.gnu.build-id section.
 class BuildIdSection : public SyntheticSection {
+public:
   // First 16 bytes are a header.
   static const unsigned headerSize = 16;
 
-public:
   const size_t hashSize;
   BuildIdSection();
   void writeTo(uint8_t *buf) override;
   size_t getSize() const override { return headerSize + hashSize; }
   void writeBuildId(llvm::ArrayRef<uint8_t> buf);
 
 private:
   uint8_t *hashBuf;

lld/ELF/Writer.cpp

void elf::addReservedSymbols() {
   // least the Android libc is that it points to the ELF header.
   addOptionalRegular("__executable_start", Out::elfHeader, 0, STV_HIDDEN);
 
   // __dso_handle symbol is passed to cxa_finalize as a marker to identify
   // each DSO. The address of the symbol doesn't matter as long as they are
   // different in different DSOs, so we chose the start address of the DSO.
   addOptionalRegular("__dso_handle", Out::elfHeader, 0, STV_HIDDEN);
 
+  if (config->buildId != BuildIdKind::None) {
+    ElfSym::buildIdStart = addOptionalRegular("__build_id_start", nullptr, 0, STV_HIDDEN);
+    ElfSym::buildIdEnd = addOptionalRegular("__build_id_end", nullptr, 0, STV_HIDDEN);
+  }
+
   // If linker script do layout we do not need to create any standard symbols.
   if (script->hasSectionsCommand)
     return;
 
   auto add = [](StringRef s, int64_t pos) {
     return addOptionalRegular(s, Out::elfHeader, pos, STV_DEFAULT);
   };
 
if (ElfSym::mipsGp) {
     for (OutputSection *os : outputSections) {
       if (os->flags & SHF_MIPS_GPREL) {
         ElfSym::mipsGp->section = os;
         ElfSym::mipsGp->value = 0x7ff0;
         break;
       }
     }
   }
+
+  // __build_id_start and __build_id_end points to the build ID.
+  if (config->buildId != BuildIdKind::None) {
+    ElfSym::buildIdStart->section = mainPart->buildId;
+    ElfSym::buildIdStart->value = BuildIdSection::headerSize;
+    ElfSym::buildIdEnd->section = mainPart->buildId;
+    ElfSym::buildIdEnd->value = mainPart->buildId->getSize();
+  }
 }
 
 // We want to find how similar two ranks are.
 // The more branches in getSectionRank that match, the more similar they are.
 // Since each branch corresponds to a bit flag, we can just use
 // countLeadingZeros.
 static int getRankProximityAux(OutputSection *a, OutputSection *b) {
   return countLeadingZeros(a->sortRank ^ b->sortRank);

lld/test/ELF/build-id.s

 # REQUIRES: x86
 
 # RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
 
 # RUN: ld.lld --build-id %t -o %t2
 # RUN: llvm-readobj -S %t2 | FileCheck -check-prefix=ALIGN %s
+# RUN: llvm-readelf -S -s %t2 | FileCheck --check-prefix=SYMBOL %s
 
-# RUN: ld.lld --build-id %t -o %t2
+# RUN: ld.lld --build-id %t -o %t2 -threads
 # RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
 # RUN: ld.lld --build-id=fast %t -o %t2
 # RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
 # RUN: ld.lld --build-id %t -o %t2 --threads=1
 # RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
 
 # RUN: ld.lld --build-id=md5 %t -o %t2
 # RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=MD5 %s
 # RUN: ld.lld --build-id=md5 %t -o %t2 --threads=1

 
 .globl _start
 _start:
   nop
 
 .section .note.test, "a", @note
    .quad 42
 
+.global __build_id_start
+.global __build_id_end
+
 # ALIGN:      Name: .note.gnu.build-id
 # ALIGN-NEXT: Type: SHT_NOTE
 # ALIGN-NEXT: Flags [
 # ALIGN-NEXT:   SHF_ALLOC
 # ALIGN-NEXT: ]
 # ALIGN-NEXT: Address:
 # ALIGN-NEXT: Offset: [[_:0x[0-9A-Z]*(0|4|8|C)$]]
 # ALIGN-NEXT: Size:
 # ALIGN-NEXT: Link:
 # ALIGN-NEXT: Info:
 # ALIGN-NEXT: AddressAlignment: 4
 
+# SYMBOL: .note.gnu.build-id NOTE [[#%x,ADDR:]]
+# SYMBOL: [[#ADDR+24]] 0 NOTYPE LOCAL HIDDEN 2 __build_id_end
+# SYMBOL: [[#ADDR+16]] 0 NOTYPE LOCAL HIDDEN 2 __build_id_start
+
 # DEFAULT:      Contents of section .note.test:
 # DEFAULT:      Contents of section .note.gnu.build-id:
 # DEFAULT-NEXT: 04000000 08000000 03000000 474e5500  ............GNU.
-# DEFAULT-NEXT: 7e8ddeff 3ed41fa3
+# DEFAULT-NEXT: 8c3e113c 431ad49e
 
 # MD5:      Contents of section .note.gnu.build-id:
 # MD5-NEXT: 04000000 10000000 03000000 474e5500  ............GNU.
-# MD5-NEXT: 7b00fd9e 054ceb4b 06f64d0e 482cb476
+# MD5-NEXT: d4eb8a29 e12cc877 2bd79cd9 f237b3cb
 
 # SHA1:      Contents of section .note.gnu.build-id:
 # SHA1-NEXT: 04000000 14000000 03000000 474e5500  ............GNU.
-# SHA1-NEXT: 221a99da dd1d2bf3 05e48a91 dde8a0cb
+# SHA1-NEXT: 2f6c2fa7 55e6345f db61c4cd 5d554ba2
 
 # UUID:      Contents of section .note.gnu.build-id:
 # UUID-NEXT: 04000000 10000000 03000000 474e5500  ............GNU.
 
 # HEX:      Contents of section .note.gnu.build-id:
 # HEX-NEXT: 04000000 04000000 03000000 474e5500  ............GNU.
 # HEX-NEXT: 12345678
 
 # NONE-NOT: Contents of section .note.gnu.build-id: