Fix llvm-tblgen self-bootstrap

[bdragon]

Summary

libllvmminimal is missing a file, leading to a bootstrap failure when attempting a build with no existing llvm-tblgen.

This affects platforms such as powerpc64, which don't have llvm installed by default yet, and as such need to use libllvmminimal.a during bootstrap to build a working llvm-tblgen.

--- llvm-tblgen.full ---
c++ -O2 -pipe -I/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/obj-tools/lib/clang/libllvm -I/nest/POWER9BSD/lib/clang/include -I/nest/POWER9BSD/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp\" -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_NATIVE_ASMPARSER=LLVMInitializePowerPCAsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializePowerPCAsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializePowerPCDisassembler -DLLVM_NATIVE_TARGET=LLVMInitializePowerPCTarget -DLLVM_NATIVE_TARGETINFO=LLVMInitializePowerPCTargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializePowerPCTargetMC -ffunction-sections -fdata-sections -g1 -I/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti  -Wl,--gc-sections -static  -L/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/legacy/usr/lib -o llvm-tblgen.full  AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenHwModes.o CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o GlobalISelEmitter.o InfoByHwMode.o InstrDocsEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PredicateExpander.o PseudoLoweringEmitter.o RISCVCompressInstEmitter.o RegisterBankEmitter.o RegisterInfoEmitter.o SDNodeProperties.o SearchableTableEmitter.o SubtargetEmitter.o SubtargetFeatureInfo.o TableGen.o Types.o WebAssemblyDisassemblerEmitter.o X86DisassemblerTables.o X86EVEX2VEXTablesEmitter.o X86FoldTablesEmitter.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a -L/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw -L/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/obj-tools/lib/libthr -lpthread -legacy
/usr/obj/nest/POWER9BSD/powerpc.powerpc64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a(JSON.o): In function `llvm::formatv_object_base::formatv_object_base(llvm::StringRef, unsigned long)':
/nest/POWER9BSD/contrib/llvm/include/llvm/Support/FormatVariadic.h:93: undefined reference to `llvm::formatv_object_base::parseFormatString(llvm::StringRef)'

[dim]

Hm, this should really not be necessary, as llvm-tblgen is always built from scratch during bootstrap, if the MK_SYSTEM_COMPILER logic detects that the base system compiler doesn't match the compiler in the source checkout. Maybe this is something PowerPC specific? @emaste or @jhibbits any ideas?

@git_bdragon.rtk0.net, what are the exact make.conf and src.conf settings you are running buildworld with?

[bdragon]

make.conf:

OPTIONS_UNSET=DOCS NLS
WRKDIRPREFIX=/usr/obj

src.conf:

#OPTIONS_UNSET=DOCS NLS
#WITHOUT_FORMAT_EXTENSIONS=
WITHOUT_LLD=1
WITHOUT_BINUTILS=1
WITHOUT_BINUTILS_BOOTSTRAP=1
WITHOUT_GCC_BOOTSTRAP=1
WITHOUT_GCC=1

# temporarily broken
WITHOUT_PMC=1
#WITHOUT_BOOT=1

Buildworld was done in this case with the sytem linker being base/binutils and a custom base/gcc that has been upgraded by me to 8.2 and modified to build OpenPOWER ELFv2 objects.

I am still working on fixing LLD to properly handle symbol aliasing, so the only working linker at the moment is ports binutils. (As the in-tree binutils is way too old)

Interestingly, cross building from amd64 13-CURRENT using a modified powerpc64-gcc (which has been upgraded to gcc 8.2 as well by me) DOES succeed at a buildworld. It's only the bootstrap on a platform with no llvm tools at all that seems to fail.

It's possible that a build that is using lld will not notice this dependency of JSON.o on FormatVariadic.o. I know that LLD handles archives differently than binutils ld.

[bdragon]

I think it's possible that ld.bfd on powerpc64 is more picky than lld when it comes to missing references inside archives, because I am encountering a build failure on the main compiler as well.

--- all_subdir_usr.bin/clang/clang ---
/usr/obj/nest/POWER9BSD/powerpc.powerpc64/lib/clang/libclang/libclang.a(MicrosoftMangle.o): In function `MicrosoftMangleContextImpl':
/nest/POWER9BSD/contrib/llvm/tools/clang/lib/AST/MicrosoftMangle.cpp:401: undefined reference to `llvm::xxHash64(llvm::StringRef)'
collect2: error: ld returned 1 exit status
*** [clang.full] Error code 1

Either that or building LLVM without LLD hasn't been tested recently.

./lib/clang/libllvm/Makefile:SRCS_LLD+= Support/xxhash.cpp
should be SRCS_MIN instead, it looks like.

[bdragon]

Always include xxhash.cpp in libllvm, to fix buildworld on powerpc64 with binutils ld.

[bdragon]

This could plausibly be either that binutils ld.bfd is more picky than lld about undefined references (in code that is ultimately dead, possibly? JSON.o / MicrosoftMangle.o seem like the sort of thing to me that would end up ultimately trimmed out) or that my build went down a path that is untested on amd64.

In any case, with this patch, I can now complete a buildworld on PowerPC64 ELFv2 without having to omit clang from the build.

[markmi_dsl-only.net]

FYI: In attempting a devel/powerpc64-xtoolchain-gcc based build of head -r334018
on a powerpc64 I just had to make these two changes in order to avoid the problem
reported here: otherwise unable to build llvm-tblgen .

My cross-builds from amd64 did not need such a change.

[bdragon]

Looks like r344264 and r344798 have fixed this independently.