llvm@f69936f52973750d4746624abf9b6607827b08b1

Created attachment 24237 [details]
the crash dump

Created attachment 24238 [details]
lldb stack trace

Created attachment 24240 [details]
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.

Created attachment 24246 [details]
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.