[lld-macho] Fixed crashes when linking with incompatible-arch archives/

[oontvoo]

Summary

   
Two changes:
 - Avoid crashing in predicate functions.
   Querying the property of the Symbols via these is*() functions shouldn't crash the program - the answer should just be "false".
   Currently, having them throw UNREACHABLE already (incorrectly) crash certain code paths involving macho::validateSymbolRelocation() .

 - Simply ignore input archives with incompatible arch (changes from PRESIDENT810@)

[thakis]

Test?

[pirama]

In D156468#4539933, @thakis wrote:

Test?

https://github.com/llvm/llvm-project/issues/56386 has a reproducer that could help with the test.

[oontvoo]

updated diff

[oontvoo]

got rid of TODO in test

[oontvoo]

updated tests

[oontvoo]

@lld-macho, @thakis, @int3, et al, anyone got a few mins to review this? Thanks!

[MaskRay]

lld/test/MachO/ignore-incompat-arch.s

35

Replace cat command with --input-file=%t/x86_a.map

71

it'd be slightly better to use a call instead of a data relocation.

73

delete blank line

lld/test/MachO/objc.s

28 ↗

(On Diff #546146)

-NOT: {{.}} is slightly better than -EMPTY:. The former tests that there is no extra line while -EMPTY: may match an empty line.

[oontvoo]

lld/test/MachO/ignore-incompat-arch.s

71

Originally I'd used the normal call[q] but llvm-mc choked when compiling for arm64 and I didn't want to have two separate input for x86 vs arm64.
So I'd figured .quad is more portable - acceptable for both archs

Can you suggest an alternative?

[oontvoo]

updated tests

[MaskRay]

lld/test/MachO/ignore-incompat-arch.s

71

Ah, ok, for portability, .quad looks good.

[MaskRay]

lld/MachO/InputFiles.cpp

206

return checkCompatibility(file);

1042

if (!compatArch) cannot be triggered. Delete it.

1044

compatArch seems no longer read after the store. Can compatArch be made ArchiveFile specific?

2115

It seems that if (!mbOrErr) can be checked first, then use else if (!err)

2131

consumeError

lld/test/MachO/ignore-incompat-arch.s

15

to prevent a warning from llvm-ar

[MaskRay]

The summary seems to have an unneeded 4-space indentation.

• Simply ignore input archives with incompatible arch (changes from PRESIDENT810@)

What is PRESIDENT810@?

[oontvoo]

addressed review comments

[oontvoo]

In D156468#4558445, @MaskRay wrote:

The summary seems to have an unneeded 4-space indentation.

• Simply ignore input archives with incompatible arch (changes from PRESIDENT810@)

What is PRESIDENT810@?

Sorry, I meant the idea of peek at the first member in the archive to check its arch in addLazySymbol is taken from this commit https://github.com/PRESIDENT810/llvm-project/commit/3062d0392a7ac2d3a77a303c6af7272dbdac9db6 by PRESIDENT810

lld/MachO/InputFiles.cpp

1042

I seem to have missed the TODOs on propagating this from the parent archive to its children so we don't need to parse them - implemented that now.

1044

As mentioned in previous comment, this compatibility flag can be propagated from a parent archive to its children so the flag should be present for all InputFile

[MaskRay]

LGTM.

[MaskRay]

In D156468#4558575, @oontvoo wrote:

In D156468#4558445, @MaskRay wrote:

The summary seems to have an unneeded 4-space indentation.

• Simply ignore input archives with incompatible arch (changes from PRESIDENT810@)

What is PRESIDENT810@?

Sorry, I meant the idea of peek at the first member in the archive to check its arch in addLazySymbol is taken from this commit https://github.com/PRESIDENT810/llvm-project/commit/3062d0392a7ac2d3a77a303c6af7272dbdac9db6 by PRESIDENT810

You may want to use https://github.com/PRESIDENT810 . It's unclear that PRESIDENT810 is a username, at least to me...

[oontvoo]

Thanks!

[jhuber6]

This broke an AMDGPU buildbot https://lab.llvm.org/staging/#/builders/247/builds/4301.

[oontvoo]

In D156468#4560914, @jhuber6 wrote:

This broke an AMDGPU buildbot https://lab.llvm.org/staging/#/builders/247/builds/4301.

I think https://reviews.llvm.org/rGcd29ebb862b5c7a81c9f39c8c493f9246d6e5f0b should fix it.
Thanks!

[gulfem]

We started seeing a segmentation fault after this patch in our mac builders.

[12554/40876](1) RUST host_x64/netstack3_core_instrumented_lib_test host_x64/exe.unstripped/netstack3_core_instrumented_lib_test
FAILED: host_x64/netstack3_core_instrumented_lib_test host_x64/exe.unstripped/netstack3_core_instrumented_lib_test 
          PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
          Stack dump:
           #0 0x0000000107d536d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057e16d8)
           #1 0x0000000107d515c9 llvm::sys::RunSignalHandlers() (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057df5c9)
           #2 0x0000000107d53d66 SignalHandler(int) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057e1d66)
           #3 0x00007fff70b215fd (/usr/lib/system/libsystem_platform.dylib+0x7fff673fc5fd)
           #4 0x0000000000000000 
           #5 0x00000001077bf1d2 llvm::object::ArchiveMemberHeader::getSize() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524d1d2)
           #6 0x00000001077c09cf llvm::object::Archive::Child::getName() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524e9cf)
           #7 0x00000001077c149e llvm::object::Archive::Child::getMemoryBufferRef() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524f49e)
           #8 0x0000000104e9cf7b lld::macho::ArchiveFile::addLazySymbols() (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10292af7b)
           #9 0x0000000104e835c6 addFile(llvm::StringRef, LoadType, bool, bool, bool, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1029115c6)
          #10 0x0000000104e80852 lld::macho::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10290e852)
          #11 0x000000010537f33f lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x102e0d33f)
          #12 0x000000010263af99 lld_main(int, char**, llvm::ToolContext const&) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1000c8f99)
          #13 0x00000001028474bb findTool(int, char**, char const*) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1002d54bb)
          #14 0x00007fff70928cc9 (/usr/lib/system/libdyld.dylib+0x7fff67203cc9)
          #15 0x000000000000009f 
          clang++: error: unable to execute command: Segmentation fault: 11
          clang++: error: linker command failed due to signal (use -v to see invocation)

https://ci.chromium.org/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.x64-host_test_only-mac-subbuild/b8773677091545805297/overview

[oontvoo]

In D156468#4567838, @gulfem wrote:

We started seeing a segmentation fault after this patch in our mac builders.

[12554/40876](1) RUST host_x64/netstack3_core_instrumented_lib_test host_x64/exe.unstripped/netstack3_core_instrumented_lib_test
FAILED: host_x64/netstack3_core_instrumented_lib_test host_x64/exe.unstripped/netstack3_core_instrumented_lib_test 
          PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
          Stack dump:
           #0 0x0000000107d536d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057e16d8)
           #1 0x0000000107d515c9 llvm::sys::RunSignalHandlers() (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057df5c9)
           #2 0x0000000107d53d66 SignalHandler(int) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1057e1d66)
           #3 0x00007fff70b215fd (/usr/lib/system/libsystem_platform.dylib+0x7fff673fc5fd)
           #4 0x0000000000000000 
           #5 0x00000001077bf1d2 llvm::object::ArchiveMemberHeader::getSize() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524d1d2)
           #6 0x00000001077c09cf llvm::object::Archive::Child::getName() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524e9cf)
           #7 0x00000001077c149e llvm::object::Archive::Child::getMemoryBufferRef() const (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10524f49e)
           #8 0x0000000104e9cf7b lld::macho::ArchiveFile::addLazySymbols() (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10292af7b)
           #9 0x0000000104e835c6 addFile(llvm::StringRef, LoadType, bool, bool, bool, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1029115c6)
          #10 0x0000000104e80852 lld::macho::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x10290e852)
          #11 0x000000010537f33f lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x102e0d33f)
          #12 0x000000010263af99 lld_main(int, char**, llvm::ToolContext const&) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1000c8f99)
          #13 0x00000001028474bb findTool(int, char**, char const*) (/opt/s/w/ir/x/w/fuchsia/out/not-default/../../prebuilt/third_party/clang/mac-x64/bin/ld64.lld+0x1002d54bb)
          #14 0x00007fff70928cc9 (/usr/lib/system/libdyld.dylib+0x7fff67203cc9)
          #15 0x000000000000009f 
          clang++: error: unable to execute command: Segmentation fault: 11
          clang++: error: linker command failed due to signal (use -v to see invocation)

https://ci.chromium.org/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.x64-host_test_only-mac-subbuild/b8773677091545805297/overview

Yes, this is caused by the issue described in https://reviews.llvm.org/D157300

[thakis]

Can we revert this for now then? Trunk should be in a known-working state as much as possible.

[oontvoo]

In D156468#4570056, @thakis wrote:

Can we revert this for now then? Trunk should be in a known-working state as much as possible.

The issue + fix are already in D157300. Can we not get that submitted instead? (it's also fairly trivial)

[thakis]

Your fix is in now, so that's ok, but there was a 2-day window between things being known-bad and the fix landing. This causes needless work (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1471633). Reverting is usually much faster than fixing, so please default to revert-first to keep trunk green (unless you have a fix that's ready to land as quickly as the revert).

[gulfem]

In D156468#4574430, @thakis wrote:

Your fix is in now, so that's ok, but there was a 2-day window between things being known-bad and the fix landing. This causes needless work (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1471633). Reverting is usually much faster than fixing, so please default to revert-first to keep trunk green (unless you have a fix that's ready to land as quickly as the revert).

I confirm that https://reviews.llvm.org/D157300 fixed the issue that I reported. Reverting and relanding with a fix can save a lot time engineering time especially to toolchain maintainers when there is a confirmed issue. When a builder is broken for a few days, upcoming breakages might be masked because of that, and this makes it more difficult to bisect the new issues.

[oontvoo]

In D156468#4574588, @gulfem wrote:

In D156468#4574430, @thakis wrote:

Your fix is in now, so that's ok, but there was a 2-day window between things being known-bad and the fix landing. This causes needless work (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1471633). Reverting is usually much faster than fixing, so please default to revert-first to keep trunk green (unless you have a fix that's ready to land as quickly as the revert).

I confirm that https://reviews.llvm.org/D157300 fixed the issue that I reported. Reverting and relanding with a fix can save a lot time engineering time especially to toolchain maintainers when there is a confirmed issue. When a builder is broken for a few days, upcoming breakages might be masked because of that, and this makes it more difficult to bisect the new issues.

I understand. Sorry about this! It was breaking our internal builds too but I'd underestimated the time it took to fix-forward. Will watch out in the future.

lld/MachO/InputFiles.h

 
 protected:
   InputFile(Kind kind, MemoryBufferRef mb, bool lazy = false)
       : mb(mb), id(idCount++), lazy(lazy), fileKind(kind),
         name(mb.getBufferIdentifier()) {}
 
   InputFile(Kind, const llvm::MachO::InterfaceFile &);
 
+  // If true, this input's arch is compatiable with target.
+  bool compatArch = true;
+
 private:
   const Kind fileKind;
   const StringRef name;
 
   static int idCount;
 };
 
 struct FDE {

lld/MachO/InputFiles.cpp

if (it->target.MinDeployment > config->platformInfo.target.MinDeployment)
     warn(toString(input) + " has version " +
          it->target.MinDeployment.getAsString() +
          ", which is newer than target minimum of " +
          config->platformInfo.target.MinDeployment.getAsString());
 
   return true;
 }
 
+template <class Header>
+static bool compatWithTargetArch(const InputFile *file, const Header *hdr) {
+  uint32_t cpuType;
+  std::tie(cpuType, std::ignore) = getCPUTypeFromArchitecture(config->arch());
+
+  if (hdr->cputype != cpuType) {
+    Architecture arch =
+        getArchitectureFromCpuType(hdr->cputype, hdr->cpusubtype);
+    auto msg = config->errorForArchMismatch
+                   ? static_cast<void (*)(const Twine &)>(error)
+                   : warn;
+
+    msg(toString(file) + " has architecture " + getArchitectureName(arch) +
+        " which is incompatible with target architecture " +
+        getArchitectureName(config->arch()));
+    return false;
+  }
+
+  if (!checkCompatibility(file))
+    return false;
+  return true;
+}
+
 // This cache mostly exists to store system libraries (and .tbds) as they're
 // loaded, rather than the input archives, which are already cached at a higher
 // level, and other files like the filelist that are only read once.
 // Theoretically this caching could be more efficient by hoisting it, but that
 // would require altering many callers to track the state.
 DenseMap<CachedHashStringRef, MemoryBufferRef> macho::cachedReads;
 // Open a given file path and return it as a memory-mapped file.
 std::optional<MemoryBufferRef> macho::readFile(StringRef path) {
template <class LP> void ObjFile::parse() {
   using Header = typename LP::mach_header;
   using SegmentCommand = typename LP::segment_command;
   using SectionHeader = typename LP::section;
   using NList = typename LP::nlist;
 
   auto *buf = reinterpret_cast<const uint8_t *>(mb.getBufferStart());
   auto *hdr = reinterpret_cast<const Header *>(mb.getBufferStart());
 
-  uint32_t cpuType;
-  std::tie(cpuType, std::ignore) = getCPUTypeFromArchitecture(config->arch());
-  if (hdr->cputype != cpuType) {
-    Architecture arch =
-        getArchitectureFromCpuType(hdr->cputype, hdr->cpusubtype);
-    auto msg = config->errorForArchMismatch
-                   ? static_cast<void (*)(const Twine &)>(error)
-                   : warn;
-    msg(toString(this) + " has architecture " + getArchitectureName(arch) +
-        " which is incompatible with target architecture " +
-        getArchitectureName(config->arch()));
+  // If we've already checked the arch, then don't need to check again.
+  if (!compatArch)
     return;
-  }
-
-  if (!checkCompatibility(this))
+  if (!(compatArch = compatWithTargetArch(this, hdr)))
     return;
 
   for (auto *cmd : findCommands<linker_option_command>(hdr, LC_LINKER_OPTION)) {
     StringRef data{reinterpret_cast<const char *>(cmd + 1),
                    cmd->cmdsize - sizeof(linker_option_command)};
     parseLCLinkerOption(this, cmd->count, data);
   }
 

 }
 
 template <class LP> void ObjFile::parseLazy() {
   using Header = typename LP::mach_header;
   using NList = typename LP::nlist;
 
   auto *buf = reinterpret_cast<const uint8_t *>(mb.getBufferStart());
   auto *hdr = reinterpret_cast<const Header *>(mb.getBufferStart());
+
+  if (!compatArch)
+    return;
+  if (!(compatArch = compatWithTargetArch(this, hdr)))
+    return;
+
   const load_command *cmd = findCommand(hdr, LC_SYMTAB);
   if (!cmd)
     return;
   auto *c = reinterpret_cast<const symtab_command *>(cmd);
   ArrayRef<NList> nList(reinterpret_cast<const NList *>(buf + c->symoff),
                         c->nsyms);
   const char *strtab = reinterpret_cast<const char *>(buf) + c->stroff;
   symbols.resize(nList.size());
if (config->applicationExtension && !dylibIsAppExtensionSafe)
     warn("using '-application_extension' with unsafe dylib: " + toString(this));
 }
 
 ArchiveFile::ArchiveFile(std::unique_ptr<object::Archive> &&f, bool forceHidden)
     : InputFile(ArchiveKind, f->getMemoryBufferRef()), file(std::move(f)),
       forceHidden(forceHidden) {}
 
 void ArchiveFile::addLazySymbols() {
+  Error err = Error::success();
+  Expected<MemoryBufferRef> mbOrErr =
+      this->file->child_begin(err)->getMemoryBufferRef();
+  if (err || mbOrErr.takeError())
+    return;
+
+  if (identify_magic(mbOrErr->getBuffer()) == file_magic::macho_object) {
+    if (target->wordSize == 8)
+      compatArch = compatWithTargetArch(
+          this, reinterpret_cast<const LP64::mach_header *>(
+                    mbOrErr->getBufferStart()));
+    else
+      compatArch = compatWithTargetArch(
+          this, reinterpret_cast<const ILP32::mach_header *>(
+                    mbOrErr->getBufferStart()));
+
+    if (!compatArch)
+      return;
+  }
+
   for (const object::Archive::Symbol &sym : file->symbols())
     symtab->addLazyArchive(sym.getName(), this, sym);
 }
 
 static Expected<InputFile *>
 loadArchiveMember(MemoryBufferRef mb, uint32_t modTime, StringRef archiveName,
                   uint64_t offsetInArchive, bool forceHidden) {
   if (config->zeroModTime)
     modTime = 0;
 

lld/MachO/Symbols.h

public:
 
   bool isLive() const { return used; }
   bool isLazy() const {
     return symbolKind == LazyArchiveKind || symbolKind == LazyObjectKind;
   }
 
   virtual uint64_t getVA() const { return 0; }
 
-  virtual bool isWeakDef() const { llvm_unreachable("cannot be weak def"); }
+  virtual bool isWeakDef() const { return false; }
 
   // Only undefined or dylib symbols can be weak references. A weak reference
   // need not be satisfied at runtime, e.g. due to the symbol not being
   // available on a given target platform.
   virtual bool isWeakRef() const { return false; }
 
-  virtual bool isTlv() const { llvm_unreachable("cannot be TLV"); }
+  virtual bool isTlv() const { return false; }
 
   // Whether this symbol is in the GOT or TLVPointer sections.
   bool isInGot() const { return gotIndex != UINT32_MAX; }
 
   // Whether this symbol is in the StubsSection.
   bool isInStubs() const { return stubsIndex != UINT32_MAX; }
 
   uint64_t getStubVA() const;

lld/test/MachO/ignore-incompat-arch.s

+## Test that LLD correctly ignored archives with incompatible architecture without crashing.
+
+# RUN: rm -rf %t; split-file %s %t
+
+# RUN: llvm-mc -filetype=obj -triple=arm64-apple-macos  %t/callee.s -o %t/callee_arm64.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-macos  %t/callee.s -o %t/callee_x86_64.o
+
+# RUN: llvm-mc -filetype=obj -triple=arm64-apple-macos  %t/caller.s -o %t/caller_arm64.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-macos  %t/caller.s -o %t/caller_x86_64.o
+
+# RUN: llvm-mc -filetype=obj -triple=arm64-apple-macos  %t/main.s -o %t/main_arm64.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-macos  %t/main.s -o %t/main_x86_64.o
+
+# RUN: llvm-ar r %t/libcallee_arm64.a %t/callee_arm64.o
+# RUN: llvm-ar r %t/libcallee_x86.a %t/callee_x86_64.o
+
+# RUN: llvm-ar r %t/libcaller_arm64.a %t/caller_arm64.o
+# RUN: llvm-ar r %t/libcaller_x86.a %t/caller_x86_64.o
+
+## Symbol from the arm64 archive should be ignored even tho it appears before the x86 archive.
+# RUN: %no-fatal-warnings-lld -map %t/x86_a.map -arch x86_64 %t/main_x86_64.o %t/libcallee_arm64.a %t/libcallee_x86.a %t/libcaller_x86.a -o %t/x86_a.out 2>&1 \
+# RUN:     | FileCheck -check-prefix=X86-WARNING %s
+
+# RUN: %no-fatal-warnings-lld -map %t/x86_b.map -arch x86_64 %t/main_x86_64.o %t/libcallee_x86.a %t/libcallee_arm64.a %t/libcaller_x86.a -o %t/x86_b.out 2>&1 \
+# RUN:     | FileCheck -check-prefix=X86-WARNING %s
+
+# RUN: %no-fatal-warnings-lld -map %t/arm64_a.map -arch arm64 %t/main_arm64.o %t/libcallee_x86.a %t/libcallee_arm64.a %t/libcaller_arm64.a -o %t/arm64_a.out 2>&1 \
+# RUN:     | FileCheck -check-prefix=ARM64-WARNING %s
+
+# RUN: %no-fatal-warnings-lld -map %t/arm64_b.map -arch arm64 %t/main_arm64.o %t/libcallee_arm64.a %t/libcallee_x86.a %t/libcaller_arm64.a -o %t/arm64_b.out 2>&1 \
+# RUN:     | FileCheck -check-prefix=ARM64-WARNING %s
+
+## Verify that the output doesn't take any symbol from the in-compat archive
+# RUN: cat %t/x86_a.map | FileCheck --check-prefix=SYM-X86 %s
+# RUN: cat %t/x86_b.map | FileCheck --check-prefix=SYM-X86 %s
+
+# RUN: cat %t/arm64_a.map | FileCheck --check-prefix=SYM-ARM64 %s
+# RUN: cat %t/arm64_b.map | FileCheck --check-prefix=SYM-ARM64 %s
+
+
+# X86-WARNING: libcallee_arm64.a has architecture arm64 which is incompatible with target architecture x86_64
+
+# ARM64-WARNING: libcallee_x86.a has architecture x86_64 which is incompatible with target architecture arm64
+
+# SYM-X86-NOT: libcallee_arm64.a
+# SYM-X86: {{.+}}main_x86_64.o
+# SYM-X86: {{.+}}libcallee_x86.a(callee_x86_64.o)
+# SYM-X86: {{.+}}libcaller_x86.a(caller_x86_64.o)
+
+# SYM-ARM64-NOT: libcallee_x86.a
+# SYM-ARM64: {{.+}}main_arm64.o
+# SYM-ARM64: {{.+}}libcallee_arm64.a(callee_arm64.o)
+# SYM-ARM64: {{.+}}libcaller_arm64.a(caller_arm64.o)
+
+
+#--- callee.s
+.globl _callee
+_callee:
+  ret
+
+#--- caller.s
+.globl _caller
+_caller:
+  .quad _callee
+  ret
+
+#--- main.s
+.globl _main
+_main:
+  .quad _caller
+  ret
+