[ELF] Add --vfs[overlay|replace] flags to change library search behavior

[abrachet]

Summary

This patch --vfsoverlay analogous to clang's -ivfsoverlay, but it only changes the behavior of library (and linker script) search resolution.

This can be useful for having libraries of different names on disk than what they might be searched for. The use-case I see here is --vfsreplace which will only search for libraries in the vfs, particularly useful for ensuring no other libraries are linked implicitly by a compiler driver.

[MaskRay]

My gut feeling is that the options are poorly specified and I am unsure why we suddenly need new mechanisms like this in the linker.
Moreover, YAML usage is unnatural for an ELF linker.

I know you have stated "it is useful", but there is no information how this is used and why other alternatives are excluded and you end up deciding to add new options.
For example, an overlayfs can be used and that will transparently many other tools including binary utilities you may use.

I am also concerned with additional complexity in findFile.

[abrachet]

In D124411#3472882, @MaskRay wrote:

My gut feeling is that the options are poorly specified and I am unsure why we suddenly need new mechanisms like this in the linker.

Poorly specified in the commit message/help text, or the behavior of llvm::vfs::RedirectingFileSystem and it's yaml format are poorly specified? Or perhaps that it just affects library searching?

Moreover, YAML usage is unnatural for an ELF linker.

Noted. I choose to go this direction because clang and some of its tools already support this. You could imagine using one overlay file for both clang and lld.

I know you have stated "it is useful", but there is no information how this is used and why other alternatives are excluded and you end up deciding to add new options.

It would be used by a build system to ensure the linker always correctly resolves references to the correct place. Particularly with --vfsreplace, you can ensure the linker is only resolving library locations you explicitly intended to be linked.

FWIW, we had also considered a flag like --library-path=lib=/path/to/liblib.a, with an accompanying flag to ensure all libraries are explicitly specified by --library-path. Does that kind of a solution sound better?

For example, an overlayfs can be used and that will transparently many other tools including binary utilities you may use.

I am also concerned with additional complexity in findFile.

The semantic complexity or code complexity?

[phosek]

Another use case besides the one already described by @abrachet is better support for case preserving and case insensitive file systems.

We're aware of cases where projects that were developed on Windows or macOS assume case preserving behavior and they would use #include <foo.h> and #include <Foo.h> as well as -lfoo and -lFoo to refer to the same file. This works on Windows and macOS, but breaks on Linux.

The solution that's commonly used in these situations is ciopfs. The problem with ciopfs is that mounting FUSE filesystem typically requires root permissions and is not a great fit for automated infrastructure. ciopfs also doesn't seem to be actively maintained anymore.

Using VFS overlay has been suggested as another alternative and it is the solution we would like to use, but it's currently only supported by Clang and not by LLD which this change addresses. Ideally, we would also introduce support for --vfsoverlay into other LLVM tools in the future if needed.

I don't have a strong opinion with regards to file format. I can imagine other file formats that might be better a fit, but I think that consistency is more important in this case as we would ideally use the same overlay specification with both Clang and LLD. If we can come up with a different format that we believe would be a better fit, and we could convince the existing Clang users to switch to it, then I'd be fine with that.

[haowei]

I am working on cross compiling support for Fuchsia Clang toolchain targeting Windows and recently encountered an issue that would be the perfect use case for this case.

Error message:

➜  testproj ~/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/bin/clang-cl helloworld.cpp -o helloworld --target=x86_64-pc-windows-msvc -I../sdk/VC/Tools/MSVC/14.30.30705/include -I"../sdk/Windows Kit/10/Include/10.0.19041.0/ucrt" -D_HAS_EXCEPTIONS=0 -v /link /LIBPATH:../sdk/VC/Tools/MSVC/14.30.30705/lib/x64 /LIBPATH:"../sdk/Windows Kit/10/Lib/10.0.19041.0/um/x64"
Fuchsia clang version 15.0.0 (https://llvm.googlesource.com/a/llvm-project ec2de7490813a7593dad59f210c7ec41f1a29002)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/bin
 "/usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/bin/clang-15" -cc1 -triple x86_64-pc-windows-msvc19.20.0 -emit-obj -mrelax-all -mincremental-linker-compatible --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name helloworld.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fms-volatile -fdiagnostics-format msvc -v -fcoverage-compilation-dir=/mnt/nvme_sec/SRC/WinSDK/testproj -resource-dir /usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/lib/clang/15.0.0 -I ../sdk/VC/Tools/MSVC/14.30.30705/include -I "../sdk/Windows Kit/10/Include/10.0.19041.0/ucrt" -D _HAS_EXCEPTIONS=0 -internal-isystem /usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/lib/clang/15.0.0/include -fdeprecated-macro -fdebug-compilation-dir=/mnt/nvme_sec/SRC/WinSDK/testproj -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.20 -std=c++14 -fdelayed-template-parsing -fcolor-diagnostics -faddrsig -o /tmp/helloworld-0be692.obj -x c++ helloworld.cpp
clang -cc1 version 15.0.0 based upon LLVM 15.0.0git default target x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 ../sdk/VC/Tools/MSVC/14.30.30705/include
 ../sdk/Windows Kit/10/Include/10.0.19041.0/ucrt
 /usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/lib/clang/15.0.0/include
End of search list.
 "/usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/bin/lld-link" -out:helloworld.exe -libpath:lib/amd64 -libpath:atlmfc/lib/amd64 -libpath:/usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/lib/clang/15.0.0/lib/x86_64-pc-windows-msvc -nologo /LIBPATH:../sdk/VC/Tools/MSVC/14.30.30705/lib/x64 "/LIBPATH:../sdk/Windows Kit/10/Lib/10.0.19041.0/um/x64" /usr/local/google/home/haowei/SRC/testbed/newTQ/prebuilt/third_party/clang/linux-x64/lib/clang/15.0.0/lib/x86_64-pc-windows-msvc/clang_rt.builtins.lib /tmp/helloworld-0be692.obj
lld-link: error: could not open 'kernel32.lib': No such file or directory
lld-link: error: could not open 'libucrt.lib': No such file or directory
lld-link: error: could not open 'uuid.lib': No such file or directory
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

lld-link complaining kernel32.lib cannot be found. But in reality, these libraries are all in the search path:

➜  x64 pwd
/mnt/nvme_sec/SRC/WinSDK/sdk/Windows Kit/10/Lib/10.0.19041.0/um/x64
➜  x64 ls |grep kernel
kernel32legacylib.lib
kernel32.Lib
➜  x64

The reason that lld-link works fine on Windows but failed when I tried to cross compile for Windows under Linux is that even though NTFS is a case sensitive filesystem, Windows ignores the filesystem cases and kernel32.lib will be treated as the same as kernel32.Lib. On Linux, it is not. With vfsoverlay, we can ship a map file for known case errors to mitigate this issue for lld and it will be the least intrusive solution. Alternatively, we could use filesystems that ignores cases under Linux, however, that requires root access and it is not feasible for LuCI builders and most developers plus IO performance penalties.

Please consider accepting this patch. I believe we won't be the only ones that encounter case issues when doing cross compilation for Windows and this feature will for sure solve this issue.

[MaskRay]

We're aware of cases where projects that were developed on Windows or macOS assume case preserving behavior and they would use #include <foo.h> and #include <Foo.h> as well as -lfoo and -lFoo to refer to the same file. This works on Windows and macOS, but breaks on Linux.

The solution is to fix the buggy build script with case mismatching issues, instead of offloading the burden to the involved tools (ld.lld).

The reason that lld-link works fine on Windows but failed when I tried to cross compile for Windows under Linux is that even though NTFS is a case sensitive filesystem,

This seems to me another case that you need to fix the sysroot environment instead of adding file mapping logic to tools.
Currently you need clang and lld (lld-link or ld.lld), if you later need more tools, are you going to add the logic to all the involved tools?

---

I'll take some days off so if keep arguing, it'll probably take longer for my response.
I'd also note that I have asked some other folks and objection seems much more than support.

[haowei]

This seems to me another case that you need to fix the sysroot environment instead of adding file mapping logic to tools.
Currently you need clang and lld (lld-link or ld.lld), if you later need more tools, are you going to add the logic to all the involved tools?

I dig into this issue a bit and it looks like the "kernel32.lib" is specified using compiler pragmas (using dependent library feature), see the grep results below.

➜  sdk grep -i "kernel32.lib" -rI ./
./VC/Tools/MSVC/14.30.30705/crt/src/vcruntime/mstartup.cpp:#pragma comment(linker, "/defaultlib:kernel32.lib")
./VC/Tools/MSVC/14.30.30705/crt/src/vcruntime/initializers.cpp:    // Link with the legacy kernel32.lib for the "normal" libraries
./VC/Tools/MSVC/14.30.30705/crt/src/vcruntime/initializers.cpp:    #pragma comment(linker, "/defaultlib:kernel32.lib")
./VC/Tools/MSVC/14.30.30705/atlmfc/include/atlbase.h:#pragma comment(lib, "kernel32.lib")
./Windows Kit/10/Include/10.0.19041.0/um/oobenotification.h://    and link against the published kernel32.lib.
./Windows Kit/10/Debuggers/x86/sdk/samples/exdi/ExdiGdbSrvSample/ExdiGdbSrvSample/sources:      $(CLIENTCORE_EXTERNAL_SDK_LIB_PATH)\kernel32.lib \
./Windows Kit/10/Debuggers/x86/sdk/samples/exdi/ExdiGdbSrvSample/ExdiGdbSrvSample/ExdiGdbSrvSample.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;xmllite.lib;%(AdditionalDependencies)</AdditionalDependencies>
./Windows Kit/10/Debuggers/x64/sdk/samples/exdi/ExdiGdbSrvSample/ExdiGdbSrvSample/sources:      $(CLIENTCORE_EXTERNAL_SDK_LIB_PATH)\kernel32.lib \
./Windows Kit/10/Debuggers/x64/sdk/samples/exdi/ExdiGdbSrvSample/ExdiGdbSrvSample/ExdiGdbSrvSample.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;xmllite.lib;%(AdditionalDependencies)</AdditionalDependencies>

I agree with you that this is a sysroot issue and if it is possible, I would like to fix these cases instead of trying to mitigate it in the toolchain. However, these headers and libraries are coming from the vanilla Windows SDK and MSVCRT. They are not open source. There is no way we can "fix" them, only Microsoft can. As I explained, vfsoverlay is the least intrusive solution to this problem we found so far, the VirtualFileSystem class is part of LLVM and vfsoverlay is already supported by clang and clang-tidy. Given the close relationship between LLVM tools and the fact that they all rely on LLVM libraries I don't see why lld adopting it would be a problem.

if you later need more tools, are you going to add the logic to all the involved tools?

I doubt this is going to be needed since other tools don't have the same use cases, but if it is an LLVM tool, I don't see why it cannot be done. Very little changes will be needed as evident in this change which is also fairly small.

For example, an overlayfs can be used and that will transparently many other tools including binary utilities you may use.

If overlayfs can be done entirely in user space, I will agree it would be a good solution. Unfortunately it is not. mount command requires root permissions and in a lot of cases this access cannot be granted.

lld/ELF/Config.h

 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CodeGen.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/GlobPattern.h"
 #include "llvm/Support/PrettyStackTrace.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include <atomic>
 #include <memory>
 #include <vector>
 
 namespace lld {
 namespace elf {
 
 class InputFile;
struct Configuration {
   // mode.
   int androidMemtagMode;
   // Signal to the dynamic loader to enable heap MTE.
   bool androidMemtagHeap;
   // Signal to the dynamic loader that this binary expects stack MTE. Generally,
   // this means to map the primary and thread stacks as PROT_MTE. Note: This is
   // not supported on Android 11 & 12.
   bool androidMemtagStack;
+
+  // Virtual file system to use for library path resolution.
+  std::unique_ptr<llvm::vfs::FileSystem> vfs;
+  bool vfsonly;
 };
 
 // The only instance of Configuration struct.
 extern std::unique_ptr<Configuration> config;
 
 struct DuplicateSymbol {
   const Symbol *sym;
   const InputFile *file;

lld/ELF/Driver.cpp

static void parseClangOption(StringRef opt, const Twine &msg) {
   error(msg + ": " + StringRef(err).trim());
 }
 
 // Checks the parameter of the bti-report and cet-report options.
 static bool isValidReportString(StringRef arg) {
   return arg == "none" || arg == "warning" || arg == "error";
 }
 
+static std::pair<std::unique_ptr<llvm::vfs::FileSystem>, bool>
+getVFS(const opt::InputArgList &args) {
+  using namespace llvm::vfs;
+
+  const opt::Arg *arg = args.getLastArg(OPT_vfsoverlay, OPT_vfsreplace);
+  if (!arg)
+    return {};
+
+  auto bufOrErr = llvm::MemoryBuffer::getFile(arg->getValue());
+  if (!bufOrErr)
+    return {};
+
+  std::unique_ptr<FileSystem> vfs = vfs::getVFSFromYAML(
+      std::move(*bufOrErr), /*DiagHandler*/ nullptr, arg->getValue());
+
+  auto RedirectOnly = RedirectingFileSystem::RedirectKind::RedirectOnly;
+  bool vfsonly = arg->getSpelling() == "--vfsreplace";
+  if (vfsonly)
+    reinterpret_cast<RedirectingFileSystem *>(vfs.get())->setRedirection(
+        RedirectOnly);
+  return {std::move(vfs), vfsonly};
+}
+
 // Initializes Config members by the command line options.
 static void readConfigs(opt::InputArgList &args) {
   errorHandler().verbose = args.hasArg(OPT_verbose);
   errorHandler().vsDiagnostics =
       args.hasArg(OPT_visual_studio_diagnostics_format, false);
 
+  std::tie(config->vfs, config->vfsonly) = getVFS(args);
+
   config->allowMultipleDefinition =
       args.hasFlag(OPT_allow_multiple_definition,
                    OPT_no_allow_multiple_definition, false) ||
       hasZOption(args, "muldefs");
   config->androidMemtagHeap =
       args.hasFlag(OPT_android_memtag_heap, OPT_no_android_memtag_heap, false);
   config->androidMemtagStack = args.hasFlag(OPT_android_memtag_stack,
                                             OPT_no_android_memtag_stack, false);

lld/ELF/DriverUtils.cpp

 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Option/Option.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Host.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/TimeProfiler.h"
+#include "llvm/Support/VirtualFileSystem.h"
 
 using namespace llvm;
 using namespace llvm::sys;
 using namespace llvm::opt;
 using namespace lld;
 using namespace lld::elf;
 
 // Create OptTable
default:
       os << toString(*arg) << "\n";
     }
   }
   return std::string(data.str());
 }
 
 // Find a file by concatenating given paths. If a resulting path
 // starts with "=", the character is replaced with a --sysroot value.
-static Optional<std::string> findFile(StringRef path1, const Twine &path2) {
+static Optional<std::string> findFile(StringRef path1, const Twine &path2,
+                                      llvm::vfs::FileSystem *vfs = nullptr,
+                                      bool vfsonly = false) {
   SmallString<128> s;
   if (path1.startswith("="))
     path::append(s, config->sysroot, path1.substr(1), path2);
   else
     path::append(s, path1, path2);
 
+  Optional<vfs::Status> stat;
+  if (vfs)
+    if (auto statOrErr = vfs->status(s))
+      stat = *statOrErr;
+
+  if (vfsonly && !stat)
+    return None;
+  if (stat)
+    s = stat->getName();
+
   if (fs::exists(s))
     return std::string(s);
   return None;
 }
 
 Optional<std::string> elf::findFromSearchPaths(StringRef path) {
   for (StringRef dir : config->searchPaths)
-    if (Optional<std::string> s = findFile(dir, path))
+    if (Optional<std::string> s =
+            findFile(dir, path, config->vfs.get(), config->vfsonly))
       return s;
   return None;
 }
 
 // This is for -l<basename>. We'll look for lib<basename>.so or lib<basename>.a from
 // search paths.
 Optional<std::string> elf::searchLibraryBaseName(StringRef name) {
   for (StringRef dir : config->searchPaths) {
     if (!config->isStatic)
-      if (Optional<std::string> s = findFile(dir, "lib" + name + ".so"))
+      if (Optional<std::string> s = findFile(
+              dir, "lib" + name + ".so", config->vfs.get(), config->vfsonly))
         return s;
-    if (Optional<std::string> s = findFile(dir, "lib" + name + ".a"))
+    if (Optional<std::string> s = findFile(dir, "lib" + name + ".a",
+                                           config->vfs.get(), config->vfsonly))
       return s;
   }
   return None;
 }
 
 // This is for -l<namespec>.
 Optional<std::string> elf::searchLibrary(StringRef name) {
   llvm::TimeTraceScope timeScope("Locate library", name);

lld/ELF/Options.td

 // implicitly, so we have a specific bit in the note to signal to the loader to
 // remap the stack as PROT_MTE.
 defm android_memtag_stack: BB<"android-memtag-stack",
     "Instruct the dynamic loader to prepare for MTE stack instrumentation", "">;
 defm android_memtag_heap: BB<"android-memtag-heap",
     "Instruct the dynamic loader to enable MTE protection for the heap", "">;
 defm android_memtag_mode: EEq<"android-memtag-mode",
     "Instruct the dynamic loader to start under MTE mode {async, sync, none}">;
+
+defm vfsoverlay: EEq<"vfsoverlay",
+  "Use the filesystem overlay yaml file to change the library search path">;
+defm vfsreplace: EEq<"vfsreplace",
+  "Use the filesystem overlay yaml file to change the library search path, and don't fallback to the real filesystem">;

lld/test/ELF/vfsoverlay.test

+# REQUIRES: x86
+
+# RUN: split-file %s %t
+# RUN: llvm-mc -filetype=obj -triple=x86_64-elf %t/lib.s -o %t/lib.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-elf %t/main.s -o %t/main.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-elf %t/deplibs.s -o %t/deplibs.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-elf %t/deplibs_fallback.s -o %t/deplibs_fallback.o
+# RUN: llvm-ar rc %t/notliblib.a %t/lib.o
+# RUN: cp %t/notliblib.a %t/libfallbackrealfs.a
+# RUN: sed -e "s|REPLACE_LIBA|%t/notliblib.a|g;s|REPLACE_SCRIPT|%t/notlib.ld|g" %t/overlay.yaml.in > %t/overlay.yaml
+
+# RUN: ld.lld -o /dev/null %t/main.o -L/noexist -llib --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+# RUN: ld.lld -o /dev/null %t/main.o -L/noexist -llib --vfsreplace=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+
+# RUN: ld.lld -o /dev/null %t/main.o -L/noexist -l:liblib.a --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+# RUN: ld.lld -o /dev/null %t/main.o -L/noexist -l:liblib.a --vfsreplace=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+
+# RUN: ld.lld -o /dev/null %t/main.o -L=. -llib --sysroot="/noexist" --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+# RUN: ld.lld -o /dev/null %t/main.o -L=. -llib --sysroot="/noexist" --vfsreplace=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+
+# RUN: ld.lld -o /dev/null %t/main.o -L%t -lfallbackrealfs --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t --check-prefix=FALLBACK
+# RUN: not ld.lld -o /dev/null %t/main.o -L%t -lfallbackrealfs --vfsreplace=%t/overlay.yaml 2>&1 |\
+# RUN:   FileCheck %s --check-prefix=NOTFOUND
+
+# RUN: ld.lld -o /dev/null %t/deplibs.o -L/noexist --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+# RUN: ld.lld -o /dev/null %t/deplibs.o -L/noexist --vfsreplace=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t
+
+# RUN: ld.lld -o /dev/null %t/deplibs_fallback.o -L%t --vfsoverlay=%t/overlay.yaml --trace 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t --check-prefix=FALLBACK
+# RUN: not ld.lld -o /dev/null %t/deplibs_fallback.o -L%t --vfsreplace=%t/overlay.yaml 2>&1 |\
+# RUN:   FileCheck %s -DDIR=%t --check-prefix=NOTFOUND-DEPLIBS
+
+# Linker scripts are not emitted by --trace, but ensure that this links, thus the script was found.
+# RUN: ld.lld -o /dev/null %t/main.o -L/noexist -T lib.ld --vfsoverlay=%t/overlay.yaml
+
+# CHECK: [[DIR]]{{[\\/]}}notliblib.a
+# FALLBACK: [[DIR]]{{[\\/]}}libfallbackrealfs.a
+# NOTFOUND: error: unable to find library -lfallbackrealfs
+# NOTFOUND-DEPLIBS: unable to find library from dependent library specifier: fallbackrealfs
+
+#--- overlay.yaml.in
+{
+  'version': 0,
+  'roots' : [
+    {
+      'name': '/noexist',
+      'type': 'directory',
+      'contents': [
+        {
+          'name': 'liblib.a',
+          'type': 'file',
+          'external-contents': 'REPLACE_LIBA'
+        },
+        {
+          'name': 'lib.ld',
+          'type': 'file',
+          'external-contents': 'REPLACE_SCRIPT'
+        }
+      ]
+    }
+  ]
+}
+
+#--- lib.s
+.global sym
+sym:
+
+#--- notlib.ld
+sym = 0x0;
+
+#--- main.s
+.global _start
+_start:
+  call sym
+
+#--- deplibs.s
+.global _start
+_start:
+  call sym
+
+.section ".deplibs", "MS", @llvm_dependent_libraries, 1
+  .asciz "lib"
+
+#--- deplibs_fallback.s
+.global _start
+_start:
+  call sym
+
+.section ".deplibs", "MS", @llvm_dependent_libraries, 1
+  .asciz "fallbackrealfs"