Based on information from Dimitry Andric: https://bugs.llvm.org/show_bug.cgi?id=42478 - it does happen only for -triple aarch64-unknown-openbsd - with -stack-protector 2 I tried to find a reason for this behaviour. Please note I have no knowledge about LLVM internals, dont trust me, double check.
I'll point to OpenBSD (master branch) github links, I hope its fine with you. 1. So the crash is caused directly by: https://github.com/openbsd/src/blob/master/gnu/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp#L1500 where getValue() is called on NULL pointer. 2. I think it is caused by Global being NULL here: https://github.com/openbsd/src/blob/master/gnu/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp#L766 It should be returned from provided module as __stack_chk_guard function. https://github.com/openbsd/src/blob/master/gnu/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1658 3. This "__stack_chk_guard" function should be registered here: https://github.com/openbsd/src/blob/master/gnu/llvm/lib/CodeGen/StackProtector.cpp#L341 by insertSSPDeclarations() call but this piece of code is never executed because getStackGuard() returns earlier - getIRStackGuard() returns non-NULL value: https://github.com/openbsd/src/blob/master/gnu/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1635 Im not sure which one is valid: a. with TargetLoweringBase::getIRStackGuard() returning non-NULL value, TargetLoweringBase::getSDagStackGuard() should never be called by IRTranslator::getStackGuard() and this flow should be handled in a different manner b. or insertSSPDeclarations() should be called in StackProtector::getStackGuard() in both cases I was able to get rid of crash by the diff below (b. case). -- Krystian Index: StackProtector.cpp =================================================================== RCS file: /cvs/src/gnu/llvm/lib/CodeGen/StackProtector.cpp,v retrieving revision 1.8 diff -u -p -r1.8 StackProtector.cpp --- StackProtector.cpp 23 Jun 2019 22:05:12 -0000 1.8 +++ StackProtector.cpp 5 Jul 2019 20:41:17 -0000 @@ -322,8 +322,10 @@ bool StackProtector::RequiresStackProtec static Value *getStackGuard(const TargetLoweringBase *TLI, Module *M, IRBuilder<> &B, bool *SupportsSelectionDAGSP = nullptr) { - if (Value *Guard = TLI->getIRStackGuard(B)) + if (Value *Guard = TLI->getIRStackGuard(B)) { + TLI->insertSSPDeclarations(*M); return B.CreateLoad(Guard, true, "StackGuard"); + } // Use SelectionDAG SSP handling, since there isn't an IR guard. // > Wiadomość napisana przez Patrick Wildt <patr...@blueri.se> w dniu 05.07.2019, > o godz. 09:02: > > On Tue, Jul 02, 2019 at 02:07:22PM +0200, Krystian Lewandowski wrote: >> >>> Wiadomość napisana przez Krystian Lewandowski <k.lewandow...@me.com> w dniu >>> 01.07.2019, o godz. 21:50: >>> >>> I thought it would be a good idea to rebuild cross-tools because of LLVM >>> version bump >>> but - with recent src - I'm unable to do so: >>> $ doas make -f Makefile.cross TARGET=${target} CROSSDIR="${destdir}" >>> cross-tools >>> fails with: >>> aarch64-unknown-openbsd6: error: unable to execute command: Segmentation >>> fault >>> (core dumped) >>> >>> With updated /etc/mk.conf: >>> DEBUG=-gline-tables-only >>> (I think it’s unused for clang but disables stripping during installation?) >>> >>> and src/gnu/usr.bin/clang/Makefile.inc: >>> CPPFLAGS+= -DNDEBUG -gline-tables-only >>> (I think it’s similar to what cmake RelWithDebugInfo does.) >>> >>> I was eventually able to get debug symbols. More details in attached files. >>> I reproduced this crash on other machine. >>> >>> Is this something for LLVM team to look at? >>> >>> If anyone would like to give it a quick try, then please just follow >>> „Setup” section from: >>> https://github.com/elewarr/openbsd-arm64-src-dev >>> >>> -- >>> Krystian >>> >>> <cxa_demangle-042165.cpp.tgz><crash_log.txt><cxa_demangle-042165.sh><stack.txt> >>> >>> >> >> Reported to LLVM: https://bugs.llvm.org/show_bug.cgi?id=42478 >> >> -- >> Krystian >> > > I see this as well, what a bummer. What I can see is that if I use my > make wrapper to compile the files, and -j1, it doesn't crash. I wonder > what the big difference is. >