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 )

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 . . .

# gdb /usr/local/llvm12/bin/llc llc.core
. . .
Reading symbols from /usr/local/llvm12/bin/llc...
(No debugging symbols found in /usr/local/llvm12/bin/llc)
[New LWP 100512]
Core was generated by `/usr/local/llvm12/bin/llc -O1 -enable-tbaa -relocation-model=static -mcpu=generi'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 72424 and user 0.
#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/lib/libLLVM-12.so
#4  0x421f7130 in ?? () from /usr/local/llvm12/lib/libLLVM-12.so
#5  0x44edb94c in operator new(unsigned int) () from /lib/libc++.so.1
#6  0x4228c620 in llvm::raw_ostream::SetBuffered() () from /usr/local/llvm12/lib/libLLVM-12.so
#7  0x4228d59c in llvm::raw_ostream::write(char const*, unsigned int) () from /usr/local/llvm12/lib/libLLVM-12.so
#8  0x422aa510 in ?? () from /usr/local/llvm12/lib/libLLVM-12.so
#9  0x422ac0dc in llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) () from /usr/local/llvm12/lib/libLLVM-12.so
#10 0x422a9d1c in llvm::sys::RunSignalHandlers() () from /usr/local/llvm12/lib/libLLVM-12.so
#11 0x422acd08 in ?? () from /usr/local/llvm12/lib/libLLVM-12.so
#12 0x400eaed8 in ?? () from /lib/libthr.so.3
#13 0x400ea524 in ?? () from /lib/libthr.so.3
#14 0xffffe1a0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


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

(I do not have a copy of /tmp/ghc64754_0/ghc_6.bc . The /tmp
involved is cleaned out before the interactive stage in the
bulk run.)

 # 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