Re: LLVM broken on main (arm64)?

On Sun, Jul 27, 2025 at 4:58 AM Dimitry Andric <dim@freebsd.org> wrote:
>
> On 27 Jul 2025, at 13:33, Lexi Winter <ivy@freebsd.org> wrote:
> >
> > Dimitry Andric:
> >> On 27 Jul 2025, at 12:44, Herbert J. Skuhra <herbert@gojira.at> wrote:
> >>>
> >>> after updating from main-n279078-1f2c178e5688 to
> >>> main-n279105-9b3055d0d4bc (arm64) I have the following issue:
> >>>
> >>> $ cc
> >>> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
> >>> Stack dump:
> >>> 0.      Program arguments: cc
> >>> 1.      Compilation construction
> >>> Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
> >>> 0  libprivatellvm.so.19 0x00000edc041485ec llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 72
> >>> 1  libprivatellvm.so.19 0x00000edc041464ec llvm::sys::RunSignalHandlers() + 128
> >>> 2  libprivatellvm.so.19 0x00000edc04148d48 llvm::support::detail::provider_format_adapter<int>::format(llvm::raw_ostream&, llvm::StringRef) + 412
> >>> 3  libthr.so.3          0x00000edc06bafc38 _pthread_sigmask + 1320
> >>> Segmentation fault
> >>
> >> That's a very short trace, with no useful information. Maybe installworld was half-finished?
> >
> > i am seeing something similar on amd64 after updating past 9b3055d0d4bc:
> >
> > 1& 1? 172!freebsd15 ~/src/bsd/dev [lf/dev/pkgbase-toolchain]% cc
> >
> > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
> > Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
> > 0  libprivatellvm.so.19 0x00001ca34ed8f2c9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 57
> > 1  libprivatellvm.so.19 0x00001ca34ed8d185 llvm::sys::RunSignalHandlers() + 85
> > 2  libprivatellvm.so.19 0x00001ca34ed8f9d7 llvm::support::detail::provider_format_adapter<int>::format(llvm::raw_ostream&, llvm::StringRef) + 375
> > 3  libthr.so.3          0x00001ca352fc88ec _pthread_sigmask + 1340
> > 4  libthr.so.3          0x00001ca352fc7ebb pthread_signals_unblock_np + 1467
> > 5  libthr.so.3          0x00001ca34449d2d3 pthread_signals_unblock_np + 18446744073462962643
> > 6  libprivatellvm.so.19 0x00001ca34d5b28be llvm::cl::opt<int, false, llvm::cl::parser<int>>::~opt() + 62
> > 7  libc.so.7            0x00001ca35434131f __cxa_finalize + 351
> > [2]    5802 bus error (core dumped)  cc
> >
> > i'm using pkgbase so unlikely to be a partial install.  could it be that
> > this change requires a clean build?
>
> I think it's likely that Kevin's https://reviews.freebsd.org/D50388 / https://cgit.freebsd.org/src/commit/?id=9b3055d0d4bc is the cause: it flips MK_LLVM_ASSERTIONS from "yes" to "no" by default. My guess is that some objects, libraries or binaries do not get rebuilt, leading to inconsistencies.
>
> There probably has to be another depend-cleanup.sh hack to get over this. Another complication is that in depend-cleanup.sh you don't have access to the MK_xxx options from src.opts.mk.

That would not be fun because the idea is to allow someone to easily
toggle both directions, and not blow up the noclean build time for
everyone unconditionally whacking libprivatellvm.so or the like unless
there is a trivial way to detect the change.

I am inclined to back this out if someone can confirm simply setting
WITH_LLVM_ASSERTIONS fixed the issue.

>
> -Dimitry
>
>