Re: lang/ghc bootstrap compiler build likely using wrong llc: using /usr/local/llvm12/bin/llc despite BOOT_LLVM_VERSION=10 ( for BOOT_GHC_VERSION=8.10.7 )
Date: Fri, 26 Aug 2022 00:54:06 UTC
On 2022-Aug-25, at 14:07, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Aug-23, at 10:20, Mark Millard <marklmi@yahoo.com> wrote: > >> For ghc-9.2.4 builds, should the early: >> >> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc . . . >> >> related command activity be using: >> >> /usr/local/llvm12/bin/llc . . . >> >> commands? Or should it be using: >> >> /usr/local/llvm10/bin/llc . . . >> >> commands? >> >> What I see is only /usr/local/llvm12/bin/llc >> based despite the Makefile file listing >> BOOT_LLVM_VERSION as 10: >> >> LLVM_VERSION?= 12 >> BOOT_GHC_VERSION= 8.10.7 >> # LLVM version that bootstrap compiler uses >> BOOT_LLVM_VERSION= 10 >> >> I ask because the existing builds on the servers for armv7 again >> look like they did when a previous incorrect mix of llc versions >> had been in use. The old example was: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264192 >> >> The fix for that changed the out of memory error behavior at the >> time. The garbage-in/garbage-out status seemed to lead more out >> of memory failures. >> >> I've not checked on ld or other toolchain commands but I >> suppose that if the wrong llc is in use then the wrong >> versions of other toolchain commands is a possibility >> that should be looked into. >> >> >> OVERALL . . . >> >> If the >> >> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc . . . >> >> related activity should use: >> >> /usr/local/llvm10/bin/llc . . . >> >> then the port needs to be fixed to use the commands from >> the right toolchain. >> > > Going in a different direction, having gotten llc.core from > a poudiere bulk -i use to manually run make for lang/ghc > for this armv7 via aarchh64 context . . . > . . . (old backtrace removed) . . . Replaced with a better llc backtrace based on now having a copy of the ghc_6.bc input file in question: # gdb /usr/local/llvm12/bin/llc . . . (gdb) run -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ./ghc2478_0/ghc_6.bc -o ./ghc2478_0/ghc_7.lm_s Starting program: /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align ./ghc2478_0/ghc_6.bc -o ./ghc2478_0/ghc_7.lm_s LLVM ERROR: out of memory Allocation failed Program received signal SIGABRT, Aborted. Sent by thr_kill() from pid 32295 and user 0. 0x450240e4 in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x450240e4 in thr_kill () from /lib/libc.so.7 #1 0x44f9770c in raise () from /lib/libc.so.7 #2 0x4504f680 in abort () from /lib/libc.so.7 #3 0x421f703c in llvm::report_bad_alloc_error(char const*, bool) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #4 0x421f7130 in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #5 0x44edb94c in operator new(unsigned int) () from /lib/libc++.so.1 #6 0x42768518 in std::__1::vector<llvm::SUnit, std::__1::allocator<llvm::SUnit> >::reserve(unsigned int) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #7 0x42931678 in llvm::ScheduleDAGSDNodes::BuildSchedUnits() () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #8 0x4293231c in llvm::ScheduleDAGSDNodes::BuildSchedGraph(llvm::AAResults*) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #9 0x429280cc in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #10 0x429c08cc in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #11 0x429c0490 in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #12 0x429bfda4 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #13 0x429bdf0c in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #14 0x43e76cc8 in ?? () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #15 0x425f1440 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #16 0x423f1a90 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #17 0x423f79e4 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #18 0x423f208c in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/local/llvm12/bin/../lib/libLLVM-12.so #19 0x0002fc70 in main () (gdb) (So: before llc itself tries to deal with producing a backtrace.) > > It looks like the out of memory happens during llvm::sys::PrintStackTrace > related activity that was initiated during llvm::sys::RunSignalHandlers . > In other words: some other problem happened but the backtrace handling is > leading to a later problem that hides the original problem --or it looks > like such might be the case. > > It seems vaguely familiar that armv7 backtraces were problematical > in other examples of code that tried to print its own backtraces. > But, at this point, I do not remember any details. > > > For reference: > > The actual llc command reported is, in full: > > /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generic -mattr=+strict-align /tmp/ghc64754_0/ghc_6.bc -o /tmp/ghc64754_0/ghc_7.lm_s > (. . . removed note about not having ghc_6.bc . . .) > > # ls -Tld llc.core > -rw------- 1 root wheel 2064687104 Aug 25 19:40:34 2022 llc.core > > Also, I was using: > > # git -C /usr/ports/ diff lang/ghc > diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile > index 5939c5a318d7..aa2c64bfc1ea 100644 > --- a/lang/ghc/Makefile > +++ b/lang/ghc/Makefile > @@ -142,12 +142,16 @@ post-patch-BOOT-off: > @${REINPLACE_CMD} -e '/^docdir/d' ${BOOT_DIR}/mk/build.mk > @${REINPLACE_CMD} -e '/^htmldir/d' ${BOOT_DIR}/mk/build.mk > > +CONFIGURE_ENV_BOOTSTRAP=LLC=llc${BOOT_LLVM_VERSION} \ > + OPT=opt${BOOT_LLVM_VERSION} \ > + CLANG=clang${BOOT_LLVM_VERSION} \ > + CC=clang${BOOT_LLVM_VERSION} > pre-configure: > # Call the bootstrap script > cd ${WRKSRC}/ && ./boot > # If we are using bootstrap compiler, configure and install it into ${BOOT_DIR} > .if empty(PORT_OPTIONS:MBOOT) > - cd ${BOOT_DIR} && ${CONFIGURE_ENV} ${CONFIGURE_CMD} --prefix=${BOOT_DIR} > + cd ${BOOT_DIR} && ${CONFIGURE_ENV} ${CONFIGURE_ENV_BOOTSTRAP} ${CONFIGURE_CMD} --prefix=${BOOT_DIR} > cd ${BOOT_DIR} && PACKAGES='' ${MAKE_CMD} install > .endif > > > in order to have llvm10's tools in use for 8.10.7 activity and > llvm12's tools in use for 9.2.4 activity. (But I could be wrong > about such being necessary. It certainly is not sufficient by > itself for the overall build to work.) > === Mark Millard marklmi at yahoo.com