[ELF] Implement Dependent Libraries Feature

[bd1976llvm]

Summary

Implements a form of autolinking for ELF linkers.

RFC is here: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.

[smeenai]

(adding the correct Phabricator account for Rui)

[ruiu]

First round of review for the lld part -- this patch generally looking good. Nice and compact and should be useful. I think I like this.

lld/ELF/Config.h

124 ↗

(On Diff #193740)

We use the same name for a variable and a command line, thus IgnoreDeplibs.

lld/ELF/Driver.cpp

763 ↗

(On Diff #193740)

Maybe something like -autolink/-no-autolink is more conventional.

1500 ↗

(On Diff #193740)

nit: 0u → 0

lld/ELF/InputFiles.cpp

400 ↗

(On Diff #193740)

Please add a function comment, e.g.

An ELF object file may contain an `.autolink` section. If exists, the section contains a library name such as `m` for libm. This function resolves a given name as if it were given via -l. This ELF extension is called autolinking and currently unique to LLVM and lld.

401 ↗

(On Diff #193740)

Let's flip the condition and return early.

654 ↗

(On Diff #193740)

Flip the condition and return early.

657 ↗

(On Diff #193740)

Instead of allowing multiple names in a single .autolink section, why don't you create multiple .autolink sections?

[pcc]

lld/ELF/Config.h

124 ↗

(On Diff #193740)

Sort alphabetically.

lld/ELF/InputFiles.cpp

406 ↗

(On Diff #193740)

searchLibrary contains the support for handling flags like -l:foo; I guess if you don't want that behaviour here then it will need to be factored out of searchLibrary.

llvm/docs/Extensions.rst

291 ↗

(On Diff #193740)

*specifying

llvm/include/llvm/Object/IRSymtab.h

138 ↗

(On Diff #193740)

I think the version number needs to be incremented.

157 ↗

(On Diff #193740)

Maybe just Range<Str>?

llvm/lib/LTO/LTOModule.cpp

653 ↗

(On Diff #193740)

This could use a range for loop.

[peter.smith]

I think it will be worth adding some user level documentation, whether in this patch or another, for the pragma and how autolinking is expecting to work. My apologies I've not had time to go through the code in detail.

llvm/docs/Extensions.rst

290 ↗

(On Diff #193740)

"allows for embedding a set" could probably be worded a bit more simply. For example:
This section contains strings specifying libraries to be added to the link by the linker.

llvm/docs/LangRef.rst

6084 ↗

(On Diff #193740)

I prefer the wording of your opening sentence, "Some targets support embedding of" is it worth synchronising?

llvm/include/llvm/BinaryFormat/ELF.h

841 ↗

(On Diff #193740)

This is the same value as has been proposed in another ELF extension in https://reviews.llvm.org/D60242 , May be worth coordinating here. It is probably worth us having a central place to document the LLVM specific ELF extensions as we are accumulating enough of them.

[pcc]

llvm/include/llvm/BinaryFormat/ELF.h

841 ↗

(On Diff #193740)

I don't have any existing dependencies on the value that I've chosen. If Ben has no dependencies of his own, I reckon that whoever ends up committing first can just get this value, and the next person will get the next one. I think this can be our general policy.

Do you think that https://llvm.org/docs/Extensions.html#elf-dependent is not sufficient as a place to document our extensions?

[peter.smith]

llvm/include/llvm/BinaryFormat/ELF.h

841 ↗

(On Diff #193740)

I think it could be, now that I see it fully expanding with some of the extensions mentioning the elf terminology. I think we should mention the SHT_... and hex value so that someone doesn't have to dig for that in the source code.

[compnerd]

Am I mistaken in that this effectively prevents the use of options to handle frameworks? That really is a strong requirement and should be part of this patch.

clang/lib/CodeGen/CodeGenModule.cpp

451 ↗

(On Diff #193740)

I don't think its worth the shortening here, this is only going to be seen in the IR, so, lets spell it out (llvm.dependent.libraries or llvm.dependent-libraries sound good to me).

[bd1976llvm]

In D60274#1456362, @compnerd wrote:

Am I mistaken in that this effectively prevents the use of options to handle frameworks? That really is a strong requirement and should be part of this patch.

How so? The .linker-options implementation hasn't been modified (and is still needed for autolinking in clang 5 modules). The change in the fronted is that --dependent-lib and "comment lib" pragmas use .deplibs for ELF. Can you provide more details on your concerns?

[compnerd]

The early check for ELF is the problem. I care very little about .linker-options itself as long as the ability to ensure that framework linkage is provided (i.e. -framework ..., and '-L ...` can be passed along as options to the linker).

[bd1976llvm]

In D60274#1456450, @compnerd wrote:

The early check for ELF is the problem.

Apologies, I still don't understand this.. probably because I am a bit out of my depth modifying Clang. As this implementation is ELF only I though that the early check for ELF is appropriate. In order to support framework linking on ELF, you are going to have to re-implement the framework options in ELF specific code, no?

I care very little about .linker-options itself as long as the ability to ensure that framework linkage is provided (i.e. -framework ..., and '-L ...` can be passed along as options to the linker).

Maybe we were not on the same page after the RFC then. I am only attempting to support "comment lib" pragmas here. If we want to support framework linking with this approach the best I can offer is to change the handleDepLib function to:

static void processDepLib(StringRef Specifier, const InputFile *F) {

if (Config->DepLibs)
  if (fs::exists(Specifier))
    Driver->addFile(Specifier, /*WithLOption=*/false);
  else if (Optional<std::string> S = findFromSearchPaths(Specifier))
    Driver->addFile(*S, /*WithLOption=*/true);
  else if (Optional<std::string> S = searchLibrary(Specifier))
    Driver->addFile(*S, /*WithLOption=*/true);
  else if (Optional<std::string> S = searchFramework(Specifier))
    Driver->addFile(*S, /*WithLOption=*/true);
  else
    error(toString(F) + ": unable to find library from dependent library specifier: " + Specifier);

}

We could modify this function to warn/error if it finds two matching libraries for a specifier to *perhaps" address some of you earlier concerns.

This dependent libraries proposal doesn't handle -L options at all. If you need that and fine control over framework linking then we will need to put in .linker-options support into LLD; but, it is not clear exactly how that should work and I think it is another change distinct from this one.

[jyknight]

This commit message is rather bare-bones -- I hope that the ultimate commit message will be updated to contain more than just a reference to the RFC thread.

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

This bit seems unfortunate. "-lfoo" won't search for a file named "foo", and having this code do so does not seem like a good idea. I'd want this feature to work just like -l.

Actually, I think it'd be better to preserve the "-l" prefix in the deplibs section. (I'd note that even if libs in the search path are spelled "-lfoo", that doesn't mean we need accept any other options)

If we want to support loading a filename which not on the search path (but...do we, even? That seems like a kinda scary feature to me...), then it'd be obvious how to spell that: "libfoo.a" and "/baz/bar/foo.a" would open files directly, vs "-lfoo" and "-l:foo.a" would search for them on the search path.

[bd1976llvm]

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

What you have described is the behavior of the INPUT linker script command: https://sourceware.org/binutils/docs/ld/File-Commands.html#File-Commands.

We have carefully designed this "dependent libraries" feature to avoid mapping "comment lib" pragmas to --library command line options. My reasons:

• I don't want the compiler doing string processing to try to satisfy the command line parsing behaviour of the target linker.

• I don't want to couple the source code to a GNU-style linker. After all there are other ELF linkers. Your proposal isn't merely an ELF linking proposal, it's a proposal for ELF toolchains with GNU-like linkers (e.g. the arm linker doesn't support the colon prefix http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/Cjahbdei.html).

• The syntax is #pragma comment(lib, ...) not #pragma linker-option(library, ...) i.e. the only thing this (frankly rather bizarre) syntax definitely implies is that the argument is related to libraries (and comments ¯\_(ツ)_/¯); it is a bit of a stretch to interpret "comment lib" pragmas as mapping directly to "specifying an additional --library command line option".

• I want to avoid GNUism's and use a "general" mechanism. MSVC source code compatibility is a usecase.

• It is important to support loading a filename which not on the search path. For example I have seen developers use the following: #pragma comment(lib, FILE"\\..\\foo.lib")

I would like the following to work on for ELF:

#pragma comment(lib, "foo") => add libfoo.a to the link.
#pragma comment(lib, "foo.lib") => add foo.lib to the link
#pragma comment(lib, "c:\\foo.lib") => add c:\foo.lib to the link

The way the code is now these will work on both LLD and MSVC (and I think it will work for Apple's linker as well although I haven't checked). In addition, we have been careful to come up with a design that can be implemented by the GNU linkers... with the cost that some complicated links will not be possible to do via autolinking; in these (IMO rare) cases developers will need to use the command line directly instead.

What I am trying to accomplish is to try to keep #pragma comment(lib, "foo") compatible across linkers. Otherwise we will be in a situation where you will have to have the equivalent of...

#ifdef COFF_LIBRARIES:
#pragma comment(lib, "/DEFAULTLIB:foo.lib")
#'elif ELF_LIBRARIES_GNU_STYLE_LINKER:
#pragma comment(lib, "-lfoo")
#'elif DARWIN_FRAMEWORKS:
#pragma comment(lib, "-framework foo")
#esle
#error Please specify linking model
#endif

... in your source code (or the moral equivalent somewhere else). We can avoid this.

Also note that I am not proposing to remove the .linker-options extension. We can add support for .linker-options to LLD in the future if we find a usecase where developers want pragmas that map directly to the linkers command line options for ELF. If this is a usecase then, in the future, we can implement support for #pragma comment(linker, ....) pragmas that lower to .linker-options; #pragma comment(lib, ...) pragmas can continue to lower to .deplibs.

[MaskRay]

lld/ELF/InputFiles.cpp

658 ↗

(On Diff #193740)

ELF/EhFrame.cpp readString has an example using llvm::find(D, '\0') to prevent out-of-bounds read in case the section is corrupted.

663 ↗

(On Diff #193740)

Early return fixes fallthrough issue here.

[jyknight]

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

It just seems to me a really bad idea to have a situation where specifying #pragma comment(lib, "foo") can either open a file named "foo" in the current directory, or search for libfoo.{a,so} in the library search path.

That is pretty much guaranteed to cause problems due to unintentional filename collision in the current-directory.

[bd1976llvm]

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

Linkers already have the behaviour of finding the first matching file in the library search paths, and gnu-ld at least seems to add "." implicitly as the first library search path. So, developers already need to make sure that they don't have multiple copies of a library in the wrong place. This behaviour doesn't seem “too much” of a deviation from that. In other words I suspect that the chance of having a library named foo in the current directory and a library named libfoo.a in a library search path is remote, no?

Would your concerns be alleviated by changing the precedence, like so:

static void processDepLib(StringRef Specifier, const InputFile *F) {
  if (!Config->DepLibs)
    return;
  else if (Optional<std::string> S = searchLibrary(Specifier))
    Driver->addFile(*S, /*WithLOption=*/true);
  else if (Optional<std::string> S = findFromSearchPaths(Specifier))
      Driver->addFile(*S, /*WithLOption=*/true);
  if (fs::exists(Specifier))
      Driver->addFile(Specifier, /*WithLOption=*/false);
  else
    error(toString(F) +
          ": unable to find library from dependent library specifier: " +
          Specifier);
}

We could also change this function to error if a given specifier would find a library in more than one location (assuming that there was no early out)?

[bd1976llvm]

Addressed review comments.

[bd1976llvm]

I have updated the diff to address review comments. I think we can continue to refine this patch in parallel with discussing the design further (I am not dismissing the concerns raised by @compnerd and @jyknight).

I am unsure if I should be doing validation on the structure of the llvm.dependent-libraries named metadata e.g. what if there are zero operands or more than one operand for a metadata node. Does anyone know what LLVM's policy is?

lld/ELF/InputFiles.cpp

406 ↗

(On Diff #193740)

I was undecided here. Refactoring the code to remove the colon prefix behavior and adding other checks like only allowing libraries (not objects) to be added to the link adds complexity that might not be justified. Maybe we should simply document that some behaviors might work but are unsupported and liable to change without warning?

657 ↗

(On Diff #193740)

This would simplify the implementation but I don't think that the size increases in the input files is worth it. Also, it is easier to dump the dependent libraries if they are all in one section.

llvm/include/llvm/BinaryFormat/ELF.h

841 ↗

(On Diff #193740)

I think that it is better if the hex value is in this one place and we use the SHT_ token everywhere else. This reduces the potential for mistakes.

llvm/include/llvm/Object/IRSymtab.h

157 ↗

(On Diff #193740)

Thanks! I went for the struct with a single element representation because that is used for comdats. Should we make this same change for comdats?

[jyknight]

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

gnu-ld at least seems to add "." implicitly as the first library search path

I don't see that behavior. Neither GNU ld.bfd, GNU ld.gold, nor llvm's lld use "." as a default library search path as far as my testing can determine. Neither when invoked directly, nor when invoked through the gcc and clang drivers.

In other words I suspect that the chance of having a library named foo in the current directory and a library named libfoo.a in a library search path is remote, no?

No, I don't think the chance is remote at all. I can easily imagine linking against a library named "clang", ("libclang.so"), while having a file or directory named "clang" in the current directory, for example.

Would your concerns be alleviated by changing the precedence

No, not really.

[bd1976llvm]

lld/ELF/InputFiles.cpp

402 ↗

(On Diff #193740)

I don't see that behavior. Neither GNU ld.bfd, GNU ld.gold, nor llvm's lld use "." as a default library search path as far as my testing can determine. Neither when invoked directly, nor when invoked through the gcc and clang drivers.

I made the mistake of testing on an older copy of the binutils (from a 14.04 ubuntu). I get the same results as you with a more recent versions of the gnu tools. Apologies. Interestingly, binutils from 14.04 also allow absolute paths via -l:<absolute path> which is another behavior that has been removed.

No, I don't think the chance is remote at all. I can easily imagine linking against a library named "clang", ("libclang.so"), while having a file or directory named "clang" in the current directory, for example.

In this case are you envisioning that both of these files are competing copies of the same library, or is the "clang" in the current directory another type of file? I ask because if the "clang" in the current directory is not a library then the link will fail fast and the developer can then move this file somewhere else. If you had two different copies of the same library hanging around, then picking up the wrong one might cause bad behavior at runtime - that is the scenario that I consider to be remote.

For the example that you gave the change in precedence would be a fix, as it would cause the linker to pick up "libclang.so" and ignore "clang" in the current directory. FWIW we have been shipping with this behavior on PlayStation and it has not caused an issue for game links.

If you have a hard objection to implicitly searching in the current directory *at all* then we will have to go with another option. I would rather not remove absolute path support as it would reduce MSVC compatibility. Potential other options are:

• We could remove support for cwd-relative paths and instead check the path to see if it is absolute and load the library directly if it is.

• Another variation would be if the string contains at least one path separator, treat it as a path. That's simpler than checking for an absolute path. Users could also do 'pragma comment(lib, "./my.lib")' for relative paths too if they really wanted.

[compnerd]

lld/ELF/InputFiles.cpp

662 ↗

(On Diff #194320)

Can you make the flag here reflect the name as well? (SHT_LLVM_DEPENDENT_LIBRARIES)

lld/ELF/Options.td

74 ↗

(On Diff #194320)

I think that I prefer the --dependent-libraries flag which is similar to the recent additions to the linker options.

[bd1976llvm]

No longer shortening "dependent libraries" to "deplibs" except for the .deplibs section (as this takes up bytes on disk).

[probinson]

I'm okay with the PS4-specific bits.

[bd1976llvm]

I am keen to keep this moving.

I think there are a few things outstanding:

1. Need to resolve concerns w.r.t the design.
2. I need to find out whether I should be doing validation when reading the metadata in LLVM.
3. The LLD side needs a more detailed review.

@jyknight @compnerd can we progress the design conversation?

[ruiu]

I don't have any particular comment, and I'll give an LGTM soon as people seem to generally happy about this. If you are not happy about this patch or the feature itself, please shout. This feature is about to land.

[ruiu]

LGTM

[phosek]

@bd1976llvm do you plan on landing this? We'd really like to start using this feature.

ELF/Config.h

struct Configuration {
   bool Bsymbolic;
   bool BsymbolicFunctions;
   bool CallGraphProfileSort;
   bool CheckSections;
   bool CompressDebugSections;
   bool Cref;
   bool DefineCommon;
   bool Demangle = true;
+  bool DependentLibraries;
   bool DisableVerify;
   bool EhFrameHdr;
   bool EmitLLVM;
   bool EmitRelocs;
   bool EnableNewDtags;
   bool ExecuteOnly;
   bool ExportDynamic;
   bool FixCortexA53Errata843419;

ELF/Driver.h

 #undef OPTION
 };
 
 void printHelp();
 std::string createResponseFile(const llvm::opt::InputArgList &Args);
 
 llvm::Optional<std::string> findFromSearchPaths(StringRef Path);
 llvm::Optional<std::string> searchScript(StringRef Path);
+llvm::Optional<std::string> searchLibraryBaseName(StringRef Path);
 llvm::Optional<std::string> searchLibrary(StringRef Path);
 
 } // namespace elf
 } // namespace lld
 
 #endif

ELF/Driver.cpp

static void readConfigs(opt::InputArgList &Args) {
   Config->CheckSections =
       Args.hasFlag(OPT_check_sections, OPT_no_check_sections, true);
   Config->Chroot = Args.getLastArgValue(OPT_chroot);
   Config->CompressDebugSections = getCompressDebugSections(Args);
   Config->Cref = Args.hasFlag(OPT_cref, OPT_no_cref, false);
   Config->DefineCommon = Args.hasFlag(OPT_define_common, OPT_no_define_common,
                                       !Args.hasArg(OPT_relocatable));
   Config->Demangle = Args.hasFlag(OPT_demangle, OPT_no_demangle, true);
+  Config->DependentLibraries = Args.hasFlag(OPT_dependent_libraries, OPT_no_dependent_libraries, true);
   Config->DisableVerify = Args.hasArg(OPT_disable_verify);
   Config->Discard = getDiscard(Args);
   Config->DwoDir = Args.getLastArgValue(OPT_plugin_opt_dwo_dir_eq);
   Config->DynamicLinker = getDynamicLinker(Args);
   Config->EhFrameHdr =
       Args.hasFlag(OPT_eh_frame_hdr, OPT_no_eh_frame_hdr, false);
   Config->EmitLLVM = Args.hasArg(OPT_plugin_opt_emit_llvm, false);
   Config->EmitRelocs = Args.hasArg(OPT_emit_relocs);
template <class ELFT> void LinkerDriver::link(opt::InputArgList &Args) {
   if (Config->Entry.empty() && !Config->Relocatable)
     Config->Entry = (Config->EMachine == EM_MIPS) ? "__start" : "_start";
 
   // Handle --trace-symbol.
   for (auto *Arg : Args.filtered(OPT_trace_symbol))
     Symtab->trace(Arg->getValue());
 
   // Add all files to the symbol table. This will add almost all
-  // symbols that we need to the symbol table.
-  for (InputFile *F : Files)
-    parseFile(F);
+  // symbols that we need to the symbol table. This process might
+  // add files to the link, via autolinking, these files are always
+  // appended to the Files vector.
+  for (size_t I = 0; I < Files.size(); ++I)
+    parseFile(Files[I]);
 
   // Now that we have every file, we can decide if we will need a
   // dynamic symbol table.
   // We need one if we were asked to export dynamic symbols or if we are
   // producing a shared library.
   // We also need one if any shared libraries are used and for pie executables
   // (probably because the dynamic linker needs it).
   Config->HasDynSymTab =

ELF/DriverUtils.cpp

 
 Optional<std::string> elf::findFromSearchPaths(StringRef Path) {
   for (StringRef Dir : Config->SearchPaths)
     if (Optional<std::string> S = findFile(Dir, Path))
       return S;
   return None;
 }
 
-// This is for -lfoo. We'll look for libfoo.so or libfoo.a from
+// This is for -l<basename>. We'll look for lib<basename>.so or lib<basename>.a from
 // search paths.
-Optional<std::string> elf::searchLibrary(StringRef Name) {
-  if (Name.startswith(":"))
-    return findFromSearchPaths(Name.substr(1));
-
+Optional<std::string> elf::searchLibraryBaseName(StringRef Name) {
   for (StringRef Dir : Config->SearchPaths) {
     if (!Config->Static)
       if (Optional<std::string> S = findFile(Dir, "lib" + Name + ".so"))
         return S;
     if (Optional<std::string> S = findFile(Dir, "lib" + Name + ".a"))
       return S;
   }
   return None;
 }
 
+// This is for -l<namespec>.
+Optional<std::string> elf::searchLibrary(StringRef Name) {
+    if (Name.startswith(":"))
+        return findFromSearchPaths(Name.substr(1));
+    return searchLibraryBaseName (Name);
+}
+
 // If a linker/version script doesn't exist in the current directory, we also
 // look for the script in the '-L' search paths. This matches the behaviour of
 // '-T', --version-script=, and linker script INPUT() command in ld.bfd.
 Optional<std::string> elf::searchScript(StringRef Name) {
   if (fs::exists(Name))
     return Name.str();
   return findFromSearchPaths(Name);
 }

ELF/InputFiles.cpp

 //===- InputFiles.cpp -----------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "InputFiles.h"
+#include "Driver.h"
 #include "InputSection.h"
 #include "LinkerScript.h"
 #include "SymbolTable.h"
 #include "Symbols.h"
 #include "SyntheticSections.h"
 #include "lld/Common/ErrorHandler.h"
 #include "lld/Common/Memory.h"
 #include "llvm/ADT/STLExtras.h"
template <class ELFT> void ObjFile<ELFT>::initializeJustSymbols() {
   for (const Elf_Shdr &Sec : ObjSections) {
     if (Sec.sh_type != SHT_SYMTAB)
       continue;
     this->initSymtab<ELFT>(ObjSections, &Sec);
     return;
   }
 }
 
+// An ELF object file may contain a `.deplibs` section. If it exists, the
+// section contains a list of library specifiers such as `m` for libm. This
+// function resolves a given name by finding the first matching library checking
+// the various ways that a library can be specified to LLD. This ELF extension
+// is a form of autolinking and is called `dependent libraries`. It is currently
+// unique to LLVM and lld.
+static void addDependentLibrary(StringRef Specifier, const InputFile *F) {
+  if (!Config->DependentLibraries)
+    return;
+  if (fs::exists(Specifier))
+    Driver->addFile(Specifier, /*WithLOption=*/false);
+  else if (Optional<std::string> S = findFromSearchPaths(Specifier))
+    Driver->addFile(*S, /*WithLOption=*/true);
+  else if (Optional<std::string> S = searchLibraryBaseName(Specifier))
+    Driver->addFile(*S, /*WithLOption=*/true);
+  else
+    error(toString(F) +
+          ": unable to find library from dependent library specifier: " +
+          Specifier);
+}
+
 template <class ELFT>
 void ObjFile<ELFT>::initializeSections(
     DenseSet<CachedHashStringRef> &ComdatGroups) {
   const ELFFile<ELFT> &Obj = this->getObj();
 
   ArrayRef<Elf_Shdr> ObjSections = CHECK(Obj.sections(), this);
   uint64_t Size = ObjSections.size();
   this->Sections.resize(Size);
case SHT_ARM_ATTRIBUTES: {
     // dynamic loaders require the presence of an attribute section for dlopen
     // to work. In a full implementation we would merge all attribute sections.
     if (In.ARMAttributes == nullptr) {
       In.ARMAttributes = make<InputSection>(*this, Sec, Name);
       return In.ARMAttributes;
     }
     return &InputSection::Discarded;
   }
+  case SHT_LLVM_DEPENDENT_LIBRARIES: {
+    if (Config->Relocatable)
+      break;
+    ArrayRef<char> Data =
+        CHECK(this->getObj().template getSectionContentsAsArray<char>(&Sec), this);
+    if (!Data.empty() && Data.back() != '\0') {
+      error(toString(this) +
+            ": corrupted dependent libraries section (unterminated string): " +
+            Name);
+      return &InputSection::Discarded;
+    }
+    for (const char *D = Data.begin(), *E = Data.end(); D < E;) {
+      StringRef S(D);
+      addDependentLibrary(S, this);
+      D += S.size() + 1;
+    }
+    return &InputSection::Discarded;
+  }
   case SHT_RELA:
   case SHT_REL: {
     // Find a relocation target section and associate this section with that.
     // Target may have been discarded if it is in a different section group
     // and the group is discarded, even though it's a violation of the
     // spec. We handle that situation gracefully by discarding dangling
     // relocation sections.
     InputSectionBase *Target = getRelocTarget(Sec);

 template <class ELFT>
 void BitcodeFile::parse(DenseSet<CachedHashStringRef> &ComdatGroups) {
   std::vector<bool> KeptComdats;
   for (StringRef S : Obj->getComdatTable())
     KeptComdats.push_back(ComdatGroups.insert(CachedHashStringRef(S)).second);
 
   for (const lto::InputFile::Symbol &ObjSym : Obj->symbols())
     Symbols.push_back(createBitcodeSymbol<ELFT>(KeptComdats, ObjSym, *this));
+
+  for (auto L : Obj->getDependentLibraries())
+    addDependentLibrary(L, this);
 }
 
 static ELFKind getELFKind(MemoryBufferRef MB, StringRef ArchiveName) {
   unsigned char Size;
   unsigned char Endian;
   std::tie(Size, Endian) = getElfArchType(MB.getBuffer());
 
   auto Fatal = [&](StringRef Msg) {

ELF/Options.td

 defm allow_shlib_undefined: B<"allow-shlib-undefined",
     "Allow unresolved references in shared libraries (default when linking a shared library)",
     "Do not allow unresolved references in shared libraries (default when linking an executable)">;
 
 defm apply_dynamic_relocs: B<"apply-dynamic-relocs",
     "Apply link-time values for dynamic relocations",
     "Do not apply link-time values for dynamic relocations (default)">;
 
+defm dependent_libraries: B<"dependent-libraries",
+    "Process dependent library specifiers from input files (default)",
+    "Ignore dependent library specifiers from input files">;
+
 defm as_needed: B<"as-needed",
     "Only set DT_NEEDED for shared libraries if used",
     "Always set DT_NEEDED for shared libraries (default)">;
 
 defm call_graph_ordering_file:
   Eq<"call-graph-ordering-file", "Layout sections to optimize the given callgraph">;
 
 defm call_graph_profile_sort: B<"call-graph-profile-sort",

test/ELF/Inputs/deplibs-lib_bar.s

+        .global bar
+bar:

test/ELF/Inputs/deplibs-lib_foo.s

+        .global foo
+foo:

test/ELF/deplibs-colon-prefix.s

+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/deplibs-lib_foo.s -o %tfoo.o
+# RUN: rm -rf %t.dir
+# RUN: mkdir -p %t.dir
+# RUN: llvm-ar rc %t.dir/foo.a %tfoo.o
+# RUN: not ld.lld %t.o -o /dev/null -L %t.dir 2>&1 | FileCheck %s -DOBJ=%t.o
+# CHECK: error: [[OBJ]]: unable to find library from dependent library specifier: :foo.a
+
+        .global _start
+_start:
+        call foo
+    .section ".deplibs","MS",@llvm_dependent_libraries,1
+        .asciz  ":foo.a"

test/ELF/deplibs-corrupt.s

+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+# RUN: not ld.lld %t.o -o /dev/null -L %t.dir 2>&1 | FileCheck %s -DOBJ=%t.o
+# CHECK: error: [[OBJ]]: corrupted dependent libraries section (unterminated string): .deplibs
+
+.section ".deplibs","MS",@llvm_dependent_libraries,1
+    .ascii  ":foo.a"

test/ELF/deplibs.s

+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/deplibs-lib_foo.s -o %tfoo.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/deplibs-lib_bar.s -o %tbar.o
+# RUN: rm -rf %t.dir %t.cwd
+# RUN: mkdir -p %t.dir
+
+# error if dependent libraries cannot be found
+# RUN: not ld.lld %t.o -o /dev/null 2>&1 | FileCheck %s -DOBJ=%t.o --check-prefix MISSING
+# MISSING: error: [[OBJ]]: unable to find library from dependent library specifier: foo.a
+# MISSING-NEXT: error: [[OBJ]]: unable to find library from dependent library specifier: bar
+
+# can ignore dependent libraries
+# RUN: not ld.lld %t.o -o /dev/null --no-dependent-libraries 2>&1 | FileCheck %s --check-prefix IGNORE
+# IGNORE: error: undefined symbol: foo
+# IGNORE: error: undefined symbol: bar
+
+# -r links preserve dependent libraries
+# RUN: ld.lld %t.o %t.o -r -o %t-r.o
+# RUN: not ld.lld %t-r.o -o /dev/null 2>&1 | sort | FileCheck %s -DOBJ=%t-r.o --check-prefixes MINUSR
+# MINUSR: error: [[OBJ]]: unable to find library from dependent library specifier: bar
+# MINUSR-NEXT: error: [[OBJ]]: unable to find library from dependent library specifier: foo.a
+# MINUSR-NOT: unable to find library from dependent library specifier
+
+# static archives located relative to library search paths
+# RUN: llvm-ar rc %t.dir/foo.a %tfoo.o
+# RUN: llvm-ar rc %t.dir/libbar.a %tbar.o
+# RUN: ld.lld %t.o -o /dev/null -L %t.dir
+
+# shared objects located relative to library search paths
+# RUN: rm %t.dir/libbar.a
+# RUN: ld.lld -shared -o %t.dir/libbar.so %tbar.o
+# RUN: ld.lld -Bdynamic %t.o -o /dev/null -L %t.dir
+
+# dependent libraries searched for symbols after libraries on the command line
+# RUN: mkdir -p %t.cwd
+# RUN: cd %t.cwd
+# RUN: cp %t.dir/foo.a %t.cwd/libcmdline.a
+# RUN: ld.lld %t.o libcmdline.a -o /dev/null -L %t.dir --trace 2>&1 | FileCheck %s -DOBJ=%t.o -DSO=%t.dir --check-prefix CMDLINE --implicit-check-not foo.a
+# CMDLINE: [[OBJ]]
+# CMDLINE-NEXT: {{^libcmdline\.a}}
+# CMDLINE-NEXT: [[SO]]{{[\\/]}}libbar.so
+
+# libraries can be found from specifiers as if the specifiers were listed on on the command-line.
+# RUN: cp %t.dir/foo.a %t.cwd/foo.a
+# RUN: ld.lld %t.o -o /dev/null -L %t.dir --trace 2>&1 | FileCheck %s -DOBJ=%t.o -DSO=%t.dir --check-prefix ASIFCMDLINE --implicit-check-not foo.a
+# ASIFCMDLINE: [[OBJ]]
+# ASIFCMDLINE-NEXT: {{^foo\.a}}
+# ASIFCMDLINE-NEXT: [[SO]]{{[\\/]}}libbar.so
+
+    call foo
+    call bar
+.section ".deplibs","MS",@llvm_dependent_libraries,1
+    .asciz  "foo.a"
+    .asciz  "bar"

test/ELF/lto/deplibs.s

+; REQUIRES: x86
+
+; RUN: llvm-as %s -o %t.o
+; RUN: not ld.lld -shared %t.o -o /dev/null 2>&1 | FileCheck %s -DOBJ=%t.o
+
+; CHECK: error: [[OBJ]]: unable to find library from dependent library specifier: foo
+; CHECK: error: [[OBJ]]: unable to find library from dependent library specifier: bar
+
+target triple = "x86_64-unknown-linux-gnu"
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+
+!llvm.dependent-libraries = !{!0, !1}
+
+!0 = !{!"foo"}
+!1 = !{!"bar"}