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