assigned to @int3

f69936f

the crash dump

lldb stack trace

lldb2

If you set LLD_REPRODUCE=foo.tar or pass --reproduce=foo.tar to lld, it'll create an archive you can upload that lets us reproduce the crash.

reproducer

Symbolized stack:

#​0 0x00000000026a7610 in lld::macho::InputSection::getVA at ../../lld/MachO/InputSection.cpp:29
#​1 0x00000000026acdf1 in lld::macho::Location::getVA at ../../lld/MachO/SyntheticSections.cpp:99
#​2 0x00000000026b118a in lld::macho::RebaseSection::finalizeContents()::$_0::operator() const at ../../lld/MachO/SyntheticSections.cpp:168
#​3 0x00000000026b0c52 in __gnu_cxx::__ops::_Iter_comp_iter::operator() at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/predefined_ops.h:156
#​4 0x00000000026b11ec in std::__move_median_to_first at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algo.h:82
#​5 0x00000000026b0976 in std::__unguarded_partition_pivot at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algo.h:1924
#​6 0x00000000026b078c in std::__introsort_loop at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algo.h:1958
#​7 0x00000000026b0699 in std::__sort at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algo.h:1974
#​8 0x00000000026b0622 in std::sort at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algo.h:4892
#​9 0x00000000026b05dd in llvm::sort at ../../llvm/include/llvm/ADT/STLExtras.h:1464
#​10 0x00000000026ad093 in llvm::sort at ../../llvm/include/llvm/ADT/STLExtras.h:1469
#​11 0x00000000026acf00 in lld::macho::RebaseSection::finalizeContents at ../../lld/MachO/SyntheticSections.cpp:167
#​12 0x00000000026ce0b0 in (anonymous namespace)::Writer::run at ../../lld/MachO/Writer.cpp:712
#​13 0x00000000026cde5a in lld::macho::writeResult () at ../../lld/MachO/Writer.cpp:735
#​14 0x000000000267b3ac in lld::macho::link at ../../lld/MachO/Driver.cpp:826
#​15 0x00000000021e4cb1 in lldMain at ../../lld/tools/lld/lld.cpp:159
#​16 0x00000000021e48e7 in main at ../../lld/tools/lld/lld.cpp:211

So we're trying to sort the synthetic section locations and then hit an InputSection without parent. It's a debug section:

(gdb) p this->name
$7 = {static npos = 18446744073709551615, Data = 0x7ffff5a7e388 "__debug_ranges", Length = 14}
(gdb) p this->segname
$8 = {static npos = 18446744073709551615, Data = 0x7ffff5a7e398 "__DWARF", Length = 7}

Here's a small stand-alone repro:

$ cat test.cc
struct A {
A() : a(0) {}
int a;
} a;

$ out/gn/bin/clang --target=x86_64-apple-macos test.cc -g -c

$ out/gn/bin/ld64.lld.darwinnew -dylib test.o
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: out/gn/bin/ld64.lld.darwinnew -dylib test.o
...

This assert finds the parent-less InputSection Location that we later crash on:

$ git diff
diff --git a/lld/MachO/Writer.cpp b/lld/MachO/Writer.cpp
index fc4e36c9eb5..d2b5c9029bf 100644
--- a/lld/MachO/Writer.cpp
+++ b/lld/MachO/Writer.cpp
@@ -394,8 +394,10 @@ void Writer::scanRelocations() {
target->prepareSymbolRelocation(s, isec, r);
} else {
assert(r.referent.is<InputSection *>());

•    if (!r.pcrel)
  

•    if (!r.pcrel) {
  

•      assert(isec->parent);
       in.rebase->addEntry(isec, r.offset);
  

•    }
   }
  

  }
  }

It's hit here (with the repro in comment 8), and adding an && isec->parent to the other if makes the crash go away. However it also breaks MachO/x86-64-reloc-unsigned.s

Should we link __DWARF,__debug_ranges at all or should we just refer to the .o files like with other debug info? (I don't know the debug info handling of the linker well.)

I used the open-source clang. The most interesting flags are probably:
-O3 -g0 -glldb

Should we link __DWARF,__debug_ranges at all or should we just refer to the .o files like with other debug info?

We don't emit any debug info section, including __debug_ranges. The problem here is that the debug sections are filtered out late in the link process, after rebase/bind opcodes have been emitted for them. I think filtering them out during the parsing stage would be the best fix... I'll put up a diff for it later.