[llvm-objcopy] Delete --build-id-link-{dir,input,output}

[MaskRay]

Summary

The few options are niche. They solved a problem which was traditionally solved
with more shell commands (llvm-readelf -n fetches the Build ID. Then
ln is used to hard link the file to a directory derived from the Build ID.)

Due to limitation, they are no longer used by Fuchsia and they don't appear to
be used elsewhere (checked with Google Search and Debian Code Search). So delete
them without a transition period.

Announcement: https://lists.llvm.org/pipermail/llvm-dev/2021-February/148446.html

[phosek]

LGTM

[jhenderson]

No longer used by Fuchsia and not used elsewhere.

How can you be sure this isn't used outside Google and the LLVM upstream repo?

I'm not necessarily opposed to this (it's not in our downstream users' documentation, and we don't support it in our downstream toolchain), but what are you going to do if this breaks another user when this gets released in LLVM 13? If there's a reliable alternative, that's fine by me, but I'd encourage it to be in the commit message, and probably also in release notes, so that existing users (if there are any), can know what to do instead.

llvm/tools/llvm-objcopy/ELF/Object.h

446

This change seems unrelated?

[MaskRay]

In D96310#2550621, @jhenderson wrote:

No longer used by Fuchsia and not used elsewhere.

How can you be sure this isn't used outside Google and the LLVM upstream repo?

I'm not necessarily opposed to this (it's not in our downstream users' documentation, and we don't support it in our downstream toolchain), but what are you going to do if this breaks another user when this gets released in LLVM 13? If there's a reliable alternative, that's fine by me, but I'd encourage it to be in the commit message, and probably also in release notes, so that existing users (if there are any), can know what to do instead.

I am figuring out whether we can retire llvm/runtimes/llvm-strip-link.in

The functionality has llvm-readelf+ln replacement. It was implemented in llvm-objcopy for its convenience. Debian Code Search tells me that no external open-source project uses the functionality.

If it is used by some proprietary users, I think the best is an llvm-dev announcement that the options will be deleted if nobody speaks up. If nobody responds, we will delete the options.

llvm/tools/llvm-objcopy/ELF/Object.h

446

This is natural after the last public user of Contents is deleted.

It does not seem necessary to defer it to a subsequent clean-up.

[phosek]

In D96310#2551952, @MaskRay wrote:

I am figuring out whether we can retire llvm/runtimes/llvm-strip-link.in

I don't think we need it anymore for the Fuchsia toolchain build as we have since implemented a more generic mechanism providing similar functionality, but it may be also worth checking whether there are other users on llvm-dev.

The functionality has llvm-readelf+ln replacement. It was implemented in llvm-objcopy for its convenience.

There are many features in LLVM tools you could in replace with other tools and some bash/Python glue, but usually at the expense of efficiency. In Fuchsia we rely heavily on build ID and for every binary we build, we want produce both stripped and unstripped version and link them into the .build-id directory. The problem with using llvm-objcopy+llvm-readelf+ln wrapped in a script is that it's more expensive. This may not be an issue if you do this once, but in our build it happens several hundred times and that's where the overhead becomes noticeable which is why we implemented this feature in llvm-objcopy.

The reason why I'm not pushing against the removal of this feature is that we've since found out that it's insufficient on its own and we needed additional logic, but prototyping new features in llvm-objcopy is quite difficult, so we have since implemented a custom downstream tool that we use instead. I'm hoping we could eventually upstream that functionality, but either as a separate tool or as an alternative frontend for llvm-objcopy akin to llvm-strip/llvm-install-name-tool.

Debian Code Search tells me that no external open-source project uses the functionality. If it is used by some proprietary users, I think the best is an llvm-dev announcement that the options will be deleted if nobody speaks up. If nobody responds, we will delete the options.

I'd check with llvm-dev, Debian code search may not be sufficiently exhaustive.

[jhenderson]

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

If the workaround is spelt out for people, I'm not opposed, as already mentioned.

llvm/tools/llvm-objcopy/ELF/Object.h

446

I'd agree with that, except I can't see where Contents was previously being used?

[MaskRay]

In D96310#2553465, @jhenderson wrote:

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

I think we cannot and should not care about such users. For APIs, the policy is clear "downstream is on their own". Upstream contributors consider usage and can be polite by giving transition period.
This patch is removing options, so the bar is probably higher. If proprietary users want to keep features (I am a bit unclear how we should draw such a line), they should engage with the community.
Otherwise, unused features are subject to removal.

If the workaround is spelt out for people, I'm not opposed, as already mentioned.

[dblaikie]

In D96310#2554489, @MaskRay wrote:

In D96310#2553465, @jhenderson wrote:

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

I think we cannot and should not care about such users. For APIs, the policy is clear "downstream is on their own". Upstream contributors consider usage and can be polite by giving transition period.
This patch is removing options, so the bar is probably higher. If proprietary users want to keep features (I am a bit unclear how we should draw such a line), they should engage with the community.
Otherwise, unused features are subject to removal.

APIs are a bit different than the public documented command line argument (& other behavior) support for these tools. I think it's important we strive to maintain compatibility - though, yes, it varies depending on the tool, use case, etc. In this particular case if we have communication from the folks who wanted/implemented the feature, and now don't want/use it & no one else has said anything about it - I'm OK with removing it, documenting it's been removed & if some folks turn up later to say they want it, we could discuss adding it back in, potentially.

[jhenderson]

In D96310#2554489, @MaskRay wrote:

In D96310#2553465, @jhenderson wrote:

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

I think we cannot and should not care about such users.

Really? What about all the people out there who use systems where the LLVM toolchain is the default? Do you really expect every user who downloads and installs LLVM to have to monitor llvm-dev? I would think that llvm-dev is for developers who develop LLVM primarily, not for general day-to-day end users of the tools. For example, I don't pay much attention to the cfe-dev mailing list, yet I use clang in my Linux environment all the time. If an option was removed from clang at some point, and I happened to have been using it, I'd expect this change to at least be documented in the release notes, along with an alternative suggestion to allow me to solve the problem that I wanted to achieve (I'd still be somewhat annoyed that my. All I'm asking for is the workaround to be explained in the release notes or something else that is publicly visible, so that a user who is impacted by this has a clear path forward.

[MaskRay]

In D96310#2556172, @jhenderson wrote:

In D96310#2554489, @MaskRay wrote:

In D96310#2553465, @jhenderson wrote:

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

I think we cannot and should not care about such users.

Really? What about all the people out there who use systems where the LLVM toolchain is the default? Do you really expect every user who downloads and installs LLVM to have to monitor llvm-dev? I would think that llvm-dev is for developers who develop LLVM primarily, not for general day-to-day end users of the tools. For example, I don't pay much attention to the cfe-dev mailing list, yet I use clang in my Linux environment all the time. If an option was removed from clang at some point, and I happened to have been using it, I'd expect this change to at least be documented in the release notes, along with an alternative suggestion to allow me to solve the problem that I wanted to achieve (I'd still be somewhat annoyed that my. All I'm asking for is the workaround to be explained in the release notes or something else that is publicly visible, so that a user who is impacted by this has a clear path forward.

(Does your advice that we could add that simple llvm-nm option and later delete it https://reviews.llvm.org/D83152#2556189 conflict with the opinion here?)

For --build-id-link-{dir,input,output}, it is a pretty niche use case. It solved a problem which was traditionally solved, just providing a direct & fancy alternative. We have confidence that it can be unlikely used by dark web users.
For the problem, I could mark the options deprecated and let llvm-objcopy emit warnings - I don't use that because that is unnecessary and just complicates things. Yes, I'll note down the options in the release notes.

[MaskRay]

add release note
improve summary

[jhenderson]

In D96310#2557890, @MaskRay wrote:

In D96310#2556172, @jhenderson wrote:

In D96310#2554489, @MaskRay wrote:

In D96310#2553465, @jhenderson wrote:

FWIW, I suspect there are many users of LLVM out there who don't monitor llvm-dev, although an email like you sent certainly can't hurt.

I think we cannot and should not care about such users.

Really? What about all the people out there who use systems where the LLVM toolchain is the default? Do you really expect every user who downloads and installs LLVM to have to monitor llvm-dev? I would think that llvm-dev is for developers who develop LLVM primarily, not for general day-to-day end users of the tools. For example, I don't pay much attention to the cfe-dev mailing list, yet I use clang in my Linux environment all the time. If an option was removed from clang at some point, and I happened to have been using it, I'd expect this change to at least be documented in the release notes, along with an alternative suggestion to allow me to solve the problem that I wanted to achieve (I'd still be somewhat annoyed that my. All I'm asking for is the workaround to be explained in the release notes or something else that is publicly visible, so that a user who is impacted by this has a clear path forward.

(Does your advice that we could add that simple llvm-nm option and later delete it https://reviews.llvm.org/D83152#2556189 conflict with the opinion here?)

A fair comment. In my opinion, no, because the reason for deleting the llvm-nm option would be because we decided to mirror a new GNU option which served the same purpose (possibly in addition to something else). In such a case, the migration path is obvious (change the option name in your build script), although it probably should still be documented in release notes for the same reasoning as why I think outlining the migration path in relation to this patch is important.

For --build-id-link-{dir,input,output}, it is a pretty niche use case. It solved a problem which was traditionally solved, just providing a direct & fancy alternative. We have confidence that it can be unlikely used by dark web users.
For the problem, I could mark the options deprecated and let llvm-objcopy emit warnings - I don't use that because that is unnecessary and just complicates things. Yes, I'll note down the options in the release notes.

Yeah, like I've said, I've got no issue with the option being removed immediately. Just letting end users know what to do in the (hopefully unlikely) case they are using it is all I care about.

llvm/docs/ReleaseNotes.rst

127

I see what you're saying here, but perhaps "The options --build-id-link-{dir,input,output}" etc would be slightly better. My first reading of that was that you're referring to one option, which clashed with the use of "have" :)

I've seen references to llvm-readelf and ln in the review comments, but it's still not entirely clear to me how to use them to do the same thing. Just a couple of sentences saying the steps to perform to do the same thing either here or in the patch description would be nice.

128

Dumb question maybe, but what's the trailing _ for?

llvm/tools/llvm-objcopy/ELF/Object.h

446

Ping this? I have no issue with it being moved, but if it wasn't being used publicly before this patch, it probably should be a separate change.

[MaskRay]

comments

[MaskRay]

llvm/docs/ReleaseNotes.rst

128

The Embed URI syntax requires it. https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#embedded-uris-and-aliases

llvm/tools/llvm-objcopy/ELF/Object.h

446

The original patch adding the featured move the variable.

446

I checked that the variable can be moved without the patch. So I dropped it.

[jhenderson]

LGTM!

llvm/tools/llvm-objcopy/ELF/Object.h

446

Thanks. Feel free to make a separate commit to move it if you haven't already.

llvm/docs/CommandGuide/llvm-objcopy.rst

 
  Can be specified multiple times to add multiple symbols.
 
 .. option:: --allow-broken-links
 
  Allow :program:`llvm-objcopy` to remove sections even if it would leave invalid
  section references. Any invalid sh_link fields will be set to zero.
 
-.. option:: --build-id-link-dir <dir>
-
- Set the directory used by :option:`--build-id-link-input` and
- :option:`--build-id-link-output`.
-
-.. option:: --build-id-link-input <suffix>
-
- Hard-link the input to ``<dir>/xx/xxx<suffix>``, where ``<dir>`` is the directory
- specified by :option:`--build-id-link-dir`. The path used is derived from the
- hex build ID.
-
-.. option:: --build-id-link-output <suffix>
-
- Hard-link the output to ``<dir>/xx/xxx<suffix>``, where ``<dir>`` is the directory
- specified by :option:`--build-id-link-dir`. The path used is derived from the
- hex build ID.
-
 .. option:: --change-start <incr>, --adjust-start
 
  Add ``<incr>`` to the program's start address. Can be specified multiple
  times, in which case the values will be applied cumulatively.
 
 .. option:: --compress-debug-sections [<style>]
 
  Compress DWARF debug sections in the output, using the specified style.

llvm/docs/ReleaseNotes.rst

 Changes to the Debug Info
 ---------------------------------
 
 During this release ...
 
 Changes to the LLVM tools
 ---------------------------------
 
+* ``--build-id-link-{dir,input,output}`` have been deleted.
+  (`D96310 <https://reviews.llvm.org/D96310>`_)
+
 Changes to LLDB
 ---------------------------------
 
 Changes to Sanitizers
 ---------------------
 
 External Open Source Projects Using LLVM 13
 ===========================================

llvm/test/tools/llvm-objcopy/ELF/bad-build-id.test

-# RUN: yaml2obj %s -o %t
-# RUN: not llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-input=.debug %t 2>&1 >/dev/null | FileCheck %s
-
-# CHECK: build ID is smaller than two bytes
-
---- !ELF
-FileHeader:
-  Class:           ELFCLASS64
-  Data:            ELFDATA2LSB
-  Type:            ET_EXEC
-  Machine:         EM_X86_64
-Sections:
-  - Name:            .note.gnu.build-id
-    Type:            SHT_NOTE
-    Flags:           [ SHF_ALLOC ]
-    Content:         040000000100000003000000474E55004F000000
-ProgramHeaders:
-  - Type:     PT_NOTE
-    Flags:    [ PF_R ]
-    FirstSec: .note.gnu.build-id
-    LastSec:  .note.gnu.build-id

llvm/test/tools/llvm-objcopy/ELF/build-id-link-dir.test

-# RUN: yaml2obj %s -o %t
-# RUN: rm -fr %t-dir && mkdir %t-dir
-
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir %t %t2
-# RUN: not test -e %t-dir/4f/cb712aa6387724a9f465a32cd8c14b
-
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-input=.debug %t %t3
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug %t
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug
-
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-output "" --strip-sections %t %t4
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b %t4
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b
-
-# Linking the output of an inplace argument means that the file in the build-id
-# directory will be hard-linked to the resulting file.
-# RUN: cp %t %t5
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-output "" --strip-sections %t5
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b %t5
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b
-
-# Linking the input of an inplace argument means that the file in the build-id
-# directory will be hard-linked to the original file.
-# RUN: cp %t %t6
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-input=.debug --strip-sections %t6
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug %t
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug
-
-# You can use both at once.
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-output "" --build-id-link-input=.debug --strip-sections %t %t7
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug %t
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b %t7
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b
-
-# --build-id-link-output can have a suffix as well
-# RUN: llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-output=.debug --only-keep-debug %t %t8
-# RUN: cmp %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug %t8
-# RUN: rm %t-dir/4f/cb712aa6387724a9f465a32cd8c14b.debug
-
---- !ELF
-FileHeader:
-  Class:           ELFCLASS64
-  Data:            ELFDATA2LSB
-  Type:            ET_EXEC
-  Machine:         EM_X86_64
-Sections:
-  - Name:            .note.gnu.build-id
-    Type:            SHT_NOTE
-    Flags:           [ SHF_ALLOC ]
-    Content:         040000001000000003000000474E55004FCB712AA6387724A9F465A32CD8C14B
-ProgramHeaders:
-  - Type:     PT_NOTE
-    Flags:    [ PF_R ]
-    FirstSec: .note.gnu.build-id
-    LastSec:  .note.gnu.build-id

llvm/test/tools/llvm-objcopy/ELF/no-build-id-no-notes.test

-# RUN: yaml2obj %s -o %t
-# RUN: not llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-input=.debug %t 2>&1 >/dev/null | FileCheck %s
-
-# CHECK: could not find build ID
-
---- !ELF
-FileHeader:
-  Class:           ELFCLASS64
-  Data:            ELFDATA2LSB
-  Type:            ET_EXEC
-  Machine:         EM_X86_64

llvm/test/tools/llvm-objcopy/ELF/no-build-id.test

-# RUN: yaml2obj %s -o %t
-# RUN: not llvm-objcopy --build-id-link-dir=%t-dir --build-id-link-input=.debug %t 2>&1 >/dev/null | FileCheck %s -DINPUT=%t
-
-# CHECK: error: '[[INPUT]]': could not find build ID
-
---- !ELF
-FileHeader:
-  Class:           ELFCLASS64
-  Data:            ELFDATA2LSB
-  Type:            ET_EXEC
-  Machine:         EM_X86_64
-Sections:
-  - Name:            .note.foo
-    Type:            SHT_NOTE
-    Flags:           [ SHF_ALLOC ]
-    Content:         000000000000000000000000
-ProgramHeaders:
-  - Type:     PT_NOTE
-    Flags:    [ PF_R ]
-    FirstSec: .note.foo
-    LastSec:  .note.foo

llvm/tools/llvm-objcopy/COFF/COFFObjcopy.cpp

addSection(
                      Buf->getBufferSize()),
         IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_1BYTES);
   }
 
   if (!Config.AddGnuDebugLink.empty())
     if (Error E = addGnuDebugLink(Obj, Config.AddGnuDebugLink))
       return E;
 
-  if (Config.AllowBrokenLinks || !Config.BuildIdLinkDir.empty() ||
-      Config.BuildIdLinkInput || Config.BuildIdLinkOutput ||
-      !Config.SplitDWO.empty() || !Config.SymbolsPrefix.empty() ||
-      !Config.AllocSectionsPrefix.empty() || !Config.DumpSection.empty() ||
-      !Config.KeepSection.empty() || Config.NewSymbolVisibility ||
-      !Config.SymbolsToGlobalize.empty() || !Config.SymbolsToKeep.empty() ||
-      !Config.SymbolsToLocalize.empty() || !Config.SymbolsToWeaken.empty() ||
-      !Config.SymbolsToKeepGlobal.empty() || !Config.SectionsToRename.empty() ||
-      !Config.SetSectionAlignment.empty() || Config.ExtractDWO ||
-      Config.LocalizeHidden || Config.PreserveDates || Config.StripDWO ||
-      Config.StripNonAlloc || Config.StripSections ||
+  if (Config.AllowBrokenLinks || !Config.SplitDWO.empty() ||
+      !Config.SymbolsPrefix.empty() || !Config.AllocSectionsPrefix.empty() ||
+      !Config.DumpSection.empty() || !Config.KeepSection.empty() ||
+      Config.NewSymbolVisibility || !Config.SymbolsToGlobalize.empty() ||
+      !Config.SymbolsToKeep.empty() || !Config.SymbolsToLocalize.empty() ||
+      !Config.SymbolsToWeaken.empty() || !Config.SymbolsToKeepGlobal.empty() ||
+      !Config.SectionsToRename.empty() || !Config.SetSectionAlignment.empty() ||
+      Config.ExtractDWO || Config.LocalizeHidden || Config.PreserveDates ||
+      Config.StripDWO || Config.StripNonAlloc || Config.StripSections ||
       Config.StripSwiftSymbols || Config.Weaken ||
       Config.DecompressDebugSections ||
       Config.DiscardMode == DiscardType::Locals ||
       !Config.SymbolsToAdd.empty() || Config.EntryExpr) {
     return createStringError(llvm::errc::invalid_argument,
                              "option not supported by llvm-objcopy for COFF");
   }
 

llvm/tools/llvm-objcopy/CopyConfig.h

struct CopyConfig {
 
   // Only applicable when --output-format!=binary (e.g. elf64-x86-64).
   Optional<MachineInfo> OutputArch;
 
   // Advanced options
   StringRef AddGnuDebugLink;
   // Cached gnu_debuglink's target CRC
   uint32_t GnuDebugLinkCRC32;
-  StringRef BuildIdLinkDir;
-  Optional<StringRef> BuildIdLinkInput;
-  Optional<StringRef> BuildIdLinkOutput;
   Optional<StringRef> ExtractPartition;
   StringRef SplitDWO;
   StringRef SymbolsPrefix;
   StringRef AllocSectionsPrefix;
   DiscardType DiscardMode = DiscardType::None;
   Optional<StringRef> NewSymbolVisibility;
 
   // Repeated options

llvm/tools/llvm-objcopy/CopyConfig.cpp

parseObjcopyOptions(ArrayRef<const char *> ArgsArr,
   if (!Config.AddGnuDebugLink.empty()) {
     auto DebugOrErr = MemoryBuffer::getFile(Config.AddGnuDebugLink);
     if (!DebugOrErr)
       return createFileError(Config.AddGnuDebugLink, DebugOrErr.getError());
     auto Debug = std::move(*DebugOrErr);
     Config.GnuDebugLinkCRC32 =
         llvm::crc32(arrayRefFromStringRef(Debug->getBuffer()));
   }
-  Config.BuildIdLinkDir = InputArgs.getLastArgValue(OBJCOPY_build_id_link_dir);
-  if (InputArgs.hasArg(OBJCOPY_build_id_link_input))
-    Config.BuildIdLinkInput =
-        InputArgs.getLastArgValue(OBJCOPY_build_id_link_input);
-  if (InputArgs.hasArg(OBJCOPY_build_id_link_output))
-    Config.BuildIdLinkOutput =
-        InputArgs.getLastArgValue(OBJCOPY_build_id_link_output);
   Config.SplitDWO = InputArgs.getLastArgValue(OBJCOPY_split_dwo);
   Config.SymbolsPrefix = InputArgs.getLastArgValue(OBJCOPY_prefix_symbols);
   Config.AllocSectionsPrefix =
       InputArgs.getLastArgValue(OBJCOPY_prefix_alloc_sections);
   if (auto Arg = InputArgs.getLastArg(OBJCOPY_extract_partition))
     Config.ExtractPartition = Arg->getValue();
 
   for (auto Arg : InputArgs.filtered(OBJCOPY_redefine_symbol)) {

llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp

case FileFormat::Binary:
     return std::make_unique<BinaryWriter>(Obj, Buf);
   case FileFormat::IHex:
     return std::make_unique<IHexWriter>(Obj, Buf);
   default:
     return createELFWriter(Config, Obj, Buf, OutputElfType);
   }
 }
 
-template <class ELFT>
-static Expected<ArrayRef<uint8_t>>
-findBuildID(const CopyConfig &Config, const object::ELFFile<ELFT> &In) {
-  auto PhdrsOrErr = In.program_headers();
-  if (auto Err = PhdrsOrErr.takeError())
-    return createFileError(Config.InputFilename, std::move(Err));
-
-  for (const auto &Phdr : *PhdrsOrErr) {
-    if (Phdr.p_type != PT_NOTE)
-      continue;
-    Error Err = Error::success();
-    for (auto Note : In.notes(Phdr, Err))
-      if (Note.getType() == NT_GNU_BUILD_ID && Note.getName() == ELF_NOTE_GNU)
-        return Note.getDesc();
-    if (Err)
-      return createFileError(Config.InputFilename, std::move(Err));
-  }
-
-  return createFileError(Config.InputFilename,
-                         createStringError(llvm::errc::invalid_argument,
-                                           "could not find build ID"));
-}
-
-static Expected<ArrayRef<uint8_t>>
-findBuildID(const CopyConfig &Config, const object::ELFObjectFileBase &In) {
-  if (auto *O = dyn_cast<ELFObjectFile<ELF32LE>>(&In))
-    return findBuildID(Config, O->getELFFile());
-  else if (auto *O = dyn_cast<ELFObjectFile<ELF64LE>>(&In))
-    return findBuildID(Config, O->getELFFile());
-  else if (auto *O = dyn_cast<ELFObjectFile<ELF32BE>>(&In))
-    return findBuildID(Config, O->getELFFile());
-  else if (auto *O = dyn_cast<ELFObjectFile<ELF64BE>>(&In))
-    return findBuildID(Config, O->getELFFile());
-
-  llvm_unreachable("Bad file format");
-}
-
 template <class... Ts>
 static Error makeStringError(std::error_code EC, const Twine &Msg,
                              Ts &&... Args) {
   std::string FullMsg = (EC.message() + ": " + Msg).str();
   return createStringError(EC, FullMsg.c_str(), std::forward<Ts>(Args)...);
 }
 
-#define MODEL_8 "%%%%%%%%"
-#define MODEL_16 MODEL_8 MODEL_8
-#define MODEL_32 (MODEL_16 MODEL_16)
-
-static Error linkToBuildIdDir(const CopyConfig &Config, StringRef ToLink,
-                              StringRef Suffix,
-                              ArrayRef<uint8_t> BuildIdBytes) {
-  SmallString<128> Path = Config.BuildIdLinkDir;
-  sys::path::append(Path, llvm::toHex(BuildIdBytes[0], /*LowerCase*/ true));
-  if (auto EC = sys::fs::create_directories(Path))
-    return createFileError(
-        Path.str(),
-        makeStringError(EC, "cannot create build ID link directory"));
-
-  sys::path::append(Path,
-                    llvm::toHex(BuildIdBytes.slice(1), /*LowerCase*/ true));
-  Path += Suffix;
-  SmallString<128> TmpPath;
-  // create_hard_link races so we need to link to a temporary path but
-  // we want to make sure that we choose a filename that does not exist.
-  // By using 32 model characters we get 128-bits of entropy. It is
-  // unlikely that this string has ever existed before much less exists
-  // on this disk or in the current working directory.
-  // Additionally we prepend the original Path for debugging but also
-  // because it ensures that we're linking within a directory on the same
-  // partition on the same device which is critical. It has the added
-  // win of yet further decreasing the odds of a conflict.
-  sys::fs::createUniquePath(Twine(Path) + "-" + MODEL_32 + ".tmp", TmpPath,
-                            /*MakeAbsolute*/ false);
-  if (auto EC = sys::fs::create_hard_link(ToLink, TmpPath)) {
-    Path.push_back('\0');
-    return makeStringError(EC, "cannot link '%s' to '%s'", ToLink.data(),
-                           Path.data());
-  }
-  // We then atomically rename the link into place which will just move the
-  // link. If rename fails something is more seriously wrong so just return
-  // an error.
-  if (auto EC = sys::fs::rename(TmpPath, Path)) {
-    Path.push_back('\0');
-    return makeStringError(EC, "cannot link '%s' to '%s'", ToLink.data(),
-                           Path.data());
-  }
-  // If `Path` was already a hard-link to the same underlying file then the
-  // temp file will be left so we need to remove it. Remove will not cause
-  // an error by default if the file is already gone so just blindly remove
-  // it rather than checking.
-  if (auto EC = sys::fs::remove(TmpPath)) {
-    TmpPath.push_back('\0');
-    return makeStringError(EC, "could not remove '%s'", TmpPath.data());
-  }
-  return Error::success();
-}
-
 static Error splitDWOToFile(const CopyConfig &Config, const Reader &Reader,
                             StringRef File, ElfType OutputElfType) {
   Expected<std::unique_ptr<Object>> DWOFile = Reader.create(false);
   if (!DWOFile)
     return DWOFile.takeError();
 
   auto OnlyKeepDWOPred = [&DWOFile](const SectionBase &Sec) {
     return onlyKeepDWOPred(**DWOFile, Sec);
Error executeObjcopyOnBinary(const CopyConfig &Config,
   Expected<std::unique_ptr<Object>> Obj =
       Reader.create(!Config.SymbolsToAdd.empty());
   if (!Obj)
     return Obj.takeError();
   // Prefer OutputArch (-O<format>) if set, otherwise infer it from the input.
   const ElfType OutputElfType =
       Config.OutputArch ? getOutputElfType(Config.OutputArch.getValue())
                         : getOutputElfType(In);
-  ArrayRef<uint8_t> BuildIdBytes;
-
-  if (!Config.BuildIdLinkDir.empty()) {
-    auto BuildIdBytesOrErr = findBuildID(Config, In);
-    if (auto E = BuildIdBytesOrErr.takeError())
-      return E;
-    BuildIdBytes = *BuildIdBytesOrErr;
-
-    if (BuildIdBytes.size() < 2)
-      return createFileError(
-          Config.InputFilename,
-          createStringError(object_error::parse_failed,
-                            "build ID is smaller than two bytes"));
-  }
-
-  if (!Config.BuildIdLinkDir.empty() && Config.BuildIdLinkInput)
-    if (Error E =
-            linkToBuildIdDir(Config, Config.InputFilename,
-                             Config.BuildIdLinkInput.getValue(), BuildIdBytes))
-      return E;
 
   if (Error E = handleArgs(Config, **Obj, Reader, OutputElfType))
     return createFileError(Config.InputFilename, std::move(E));
 
   if (Error E = writeOutput(Config, **Obj, Out, OutputElfType))
     return createFileError(Config.InputFilename, std::move(E));
-  if (!Config.BuildIdLinkDir.empty() && Config.BuildIdLinkOutput)
-    if (Error E =
-            linkToBuildIdDir(Config, Config.OutputFilename,
-                             Config.BuildIdLinkOutput.getValue(), BuildIdBytes))
-      return createFileError(Config.OutputFilename, std::move(E));
 
   return Error::success();
 }
 
 } // end namespace elf
 } // end namespace objcopy
 } // end namespace llvm

llvm/tools/llvm-objcopy/ELF/Object.h

bool operator()(const SectionBase *Lhs, const SectionBase *Rhs) const {
       // fix this we can use the lexicographic ordering on ->Addr and the
       // original index.
       if (Lhs->OriginalOffset == Rhs->OriginalOffset)
         return Lhs->OriginalIndex < Rhs->OriginalIndex;
       return Lhs->OriginalOffset < Rhs->OriginalOffset;
     }
   };
 
+  ArrayRef<uint8_t> Contents;
+
 public:
   uint32_t Type = 0;
   uint32_t Flags = 0;
   uint64_t Offset = 0;
   uint64_t VAddr = 0;
   uint64_t PAddr = 0;
   uint64_t FileSize = 0;
   uint64_t MemSize = 0;
   uint64_t Align = 0;
 
   uint32_t Index = 0;
   uint64_t OriginalOffset = 0;
   Segment *ParentSegment = nullptr;
-  ArrayRef<uint8_t> Contents;
   std::set<const SectionBase *, SectionCompare> Sections;
 
   explicit Segment(ArrayRef<uint8_t> Data) : Contents(Data) {}
   Segment() = default;
 
   const SectionBase *firstSection() const {
     if (!Sections.empty())
       return *Sections.begin();

llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp

static Error isValidMachOCannonicalName(StringRef Name) {
   if (Pair.second.size() > 16)
     return createStringError(errc::invalid_argument,
                              "too long section name: '%s'",
                              Pair.second.str().c_str());
   return Error::success();
 }
 
 static Error handleArgs(const CopyConfig &Config, Object &Obj) {
-  if (Config.AllowBrokenLinks || !Config.BuildIdLinkDir.empty() ||
-      Config.BuildIdLinkInput || Config.BuildIdLinkOutput ||
-      !Config.SplitDWO.empty() || !Config.SymbolsPrefix.empty() ||
-      !Config.AllocSectionsPrefix.empty() || !Config.KeepSection.empty() ||
-      Config.NewSymbolVisibility || !Config.SymbolsToGlobalize.empty() ||
-      !Config.SymbolsToKeep.empty() || !Config.SymbolsToLocalize.empty() ||
-      !Config.SymbolsToWeaken.empty() || !Config.SymbolsToKeepGlobal.empty() ||
-      !Config.SectionsToRename.empty() ||
+  if (Config.AllowBrokenLinks || !Config.SplitDWO.empty() ||
+      !Config.SymbolsPrefix.empty() || !Config.AllocSectionsPrefix.empty() ||
+      !Config.KeepSection.empty() || Config.NewSymbolVisibility ||
+      !Config.SymbolsToGlobalize.empty() || !Config.SymbolsToKeep.empty() ||
+      !Config.SymbolsToLocalize.empty() || !Config.SymbolsToWeaken.empty() ||
+      !Config.SymbolsToKeepGlobal.empty() || !Config.SectionsToRename.empty() ||
       !Config.UnneededSymbolsToRemove.empty() ||
       !Config.SetSectionAlignment.empty() || !Config.SetSectionFlags.empty() ||
       Config.ExtractDWO || Config.LocalizeHidden || Config.PreserveDates ||
       Config.StripAllGNU || Config.StripDWO || Config.StripNonAlloc ||
       Config.StripSections || Config.Weaken || Config.DecompressDebugSections ||
       Config.StripUnneeded || Config.DiscardMode == DiscardType::Locals ||
       !Config.SymbolsToAdd.empty() || Config.EntryExpr) {
     return createStringError(llvm::errc::invalid_argument,

llvm/tools/llvm-objcopy/ObjcopyOpts.td

 defm prefix_symbols
     : Eq<"prefix-symbols", "Add <prefix> to the start of every symbol name">,
       MetaVarName<"prefix">;
 
 defm prefix_alloc_sections
     : Eq<"prefix-alloc-sections", "Add <prefix> to the start of every allocated section name">,
       MetaVarName<"prefix">;
 
-defm build_id_link_dir
-    : Eq<"build-id-link-dir", "Set directory for --build-id-link-input and "
-                              "--build-id-link-output to <dir>">,
-      MetaVarName<"dir">;
-defm build_id_link_input
-    : Eq<"build-id-link-input", "Hard-link the input to <dir>/xx/xxx<suffix> "
-                                "name derived from hex build ID">,
-      MetaVarName<"suffix">;
-defm build_id_link_output
-    : Eq<"build-id-link-output", "Hard-link the output to <dir>/xx/xxx<suffix> "
-                                 "name derived from hex build ID">,
-      MetaVarName<"suffix">;
-
 defm set_start : Eq<"set-start", "Set the start address to <addr>. Overrides "
                     "any previous --change-start or --adjust-start values.">,
                  MetaVarName<"addr">;
 defm change_start : Eq<"change-start", "Add <incr> to the start address. Can be "                        
                        "specified multiple times, all values will be applied "
                        "cumulatively.">,
                     MetaVarName<"incr">;
 def adjust_start : JoinedOrSeparate<["--"], "adjust-start">,

llvm/tools/llvm-objcopy/wasm/WasmObjcopy.cpp

for (StringRef Flag : Config.AddSection) {
     Sec.Name = SecName;
     std::unique_ptr<MemoryBuffer> Buf = std::move(*BufOrErr);
     Sec.Contents = makeArrayRef<uint8_t>(
         reinterpret_cast<const uint8_t *>(Buf->getBufferStart()),
         Buf->getBufferSize());
     Obj.addSectionWithOwnedContents(Sec, std::move(Buf));
   }
 
-  if (!Config.AddGnuDebugLink.empty() || !Config.BuildIdLinkDir.empty() ||
-      Config.BuildIdLinkInput || Config.BuildIdLinkOutput ||
-      Config.ExtractPartition || !Config.SplitDWO.empty() ||
-      !Config.SymbolsPrefix.empty() || !Config.AllocSectionsPrefix.empty() ||
+  if (!Config.AddGnuDebugLink.empty() || Config.ExtractPartition ||
+      !Config.SplitDWO.empty() || !Config.SymbolsPrefix.empty() ||
+      !Config.AllocSectionsPrefix.empty() ||
       Config.DiscardMode != DiscardType::None || Config.NewSymbolVisibility ||
       !Config.SymbolsToAdd.empty() || !Config.RPathToAdd.empty() ||
       !Config.OnlySection.empty() || !Config.SymbolsToGlobalize.empty() ||
       !Config.SymbolsToKeep.empty() || !Config.SymbolsToLocalize.empty() ||
       !Config.SymbolsToRemove.empty() ||
       !Config.UnneededSymbolsToRemove.empty() ||
       !Config.SymbolsToWeaken.empty() || !Config.SymbolsToKeepGlobal.empty() ||
       !Config.SectionsToRename.empty() || !Config.SetSectionAlignment.empty() ||