Date: Thu, 25 Aug 2022 17:54:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-haskell@freebsd.org, Gleb Popov <arrowd@freebsd.org>, Brooks Davis <brooks@FreeBSD.org>, =?utf-8?Q?Mika=C3=ABl_Urankar?= <mikael@FreeBSD.org> Subject: 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 ) Message-ID: <2A95FB6A-0A8B-4B98-9B07-91DEE2E461DF@yahoo.com> In-Reply-To: <8EE458FC-53BA-45F8-A097-11B83B874E7F@yahoo.com> References: <1C0A0307-647C-458B-9CA3-307867EDFEEF@yahoo.com> <8EE458FC-53BA-45F8-A097-11B83B874E7F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> For ghc-9.2.4 builds, should the early: >>=20 >> = /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc = . . . >>=20 >> related command activity be using: >>=20 >> /usr/local/llvm12/bin/llc . . . >>=20 >> commands? Or should it be using: >>=20 >> /usr/local/llvm10/bin/llc . . . >>=20 >> commands? >>=20 >> What I see is only /usr/local/llvm12/bin/llc >> based despite the Makefile file listing >> BOOT_LLVM_VERSION as 10: >>=20 >> LLVM_VERSION?=3D 12 >> BOOT_GHC_VERSION=3D 8.10.7 >> # LLVM version that bootstrap compiler uses >> BOOT_LLVM_VERSION=3D 10 >>=20 >> 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: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264192 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> OVERALL . . . >>=20 >> If the >>=20 >> = /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.7-boot/lib/ghc-8.10.7/bin/ghc = . . . >>=20 >> related activity should use: >>=20 >> /usr/local/llvm10/bin/llc . . . >>=20 >> then the port needs to be fixed to use the commands from >> the right toolchain. >>=20 >=20 > 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 . . . >=20 . . . (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=3Dstatic -mcpu=3Dgeneric = -mattr=3D+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=3Dstatic -mcpu=3Dgeneric -mattr=3D+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)=20 (So: before llc itself tries to deal with producing a backtrace.) >=20 > 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. >=20 > 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. >=20 >=20 > For reference: >=20 > The actual llc command reported is, in full: >=20 > /usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=3Dstatic = -mcpu=3Dgeneric -mattr=3D+strict-align /tmp/ghc64754_0/ghc_6.bc -o = /tmp/ghc64754_0/ghc_7.lm_s >=20 (. . . removed note about not having ghc_6.bc . . .) >=20 > # ls -Tld llc.core > -rw------- 1 root wheel 2064687104 Aug 25 19:40:34 2022 llc.core >=20 > Also, I was using: >=20 > # 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 >=20 > +CONFIGURE_ENV_BOOTSTRAP=3DLLC=3Dllc${BOOT_LLVM_VERSION} \ > + OPT=3Dopt${BOOT_LLVM_VERSION} \ > + CLANG=3Dclang${BOOT_LLVM_VERSION} \ > + CC=3Dclang${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=3D${BOOT_DIR} > + cd ${BOOT_DIR} && ${CONFIGURE_ENV} ${CONFIGURE_ENV_BOOTSTRAP} = ${CONFIGURE_CMD} --prefix=3D${BOOT_DIR} > cd ${BOOT_DIR} && PACKAGES=3D'' ${MAKE_CMD} install > .endif >=20 >=20 > 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.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A95FB6A-0A8B-4B98-9B07-91DEE2E461DF>