Bug 246274 - 11.2-STABLE/i386 to 11.3-STABLE/i386 buildworld fails: clang Abort trap
Summary: 11.2-STABLE/i386 to 11.3-STABLE/i386 buildworld fails: clang Abort trap
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.3-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-07 08:35 UTC by Eugene Grosbein
Modified: 2020-05-07 17:52 UTC (History)
3 users (show)

See Also:


Attachments
make NO_CLEAN=yes buildworld (165.15 KB, text/plain)
2020-05-07 08:35 UTC, Eugene Grosbein
no flags Details
auto-generated by clang (5.73 KB, text/plain)
2020-05-07 08:37 UTC, Eugene Grosbein
no flags Details
preprocessed AArch64InstPrinter-5a6d13.cpp (xz-compressed) (658.75 KB, application/octet-stream)
2020-05-07 08:39 UTC, Eugene Grosbein
no flags Details
/etc/src.conf (164 bytes, text/plain)
2020-05-07 08:44 UTC, Eugene Grosbein
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Grosbein freebsd_committer 2020-05-07 08:35:36 UTC
Created attachment 214222 [details]
make NO_CLEAN=yes buildworld

I've tried routinely perform source upgrade of 11.2-STABLE/i386 r341008 (clang6) upto stable/11/i386 r360772. The build fails at "stage 3: cross tools":

Building /home/obj/home/src/tmp/home/src/lib/clang/libllvm/Target/AArch64/MCTargetDesc/AArch64InstPrinter.o
c++: error: unable to execute command: Abort trap (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)

This is the same with and without CPUTYPE?=core2 in /etc/make.conf; with and without following in /etc/src.conf:

WITHOUT_LLVM_TARGET_ALL=
WITH_LLVM_TARGET_X86=
WITHOUT_CLANG_FULL=

See attached files for full build log and generated debugging info.
Comment 1 Eugene Grosbein freebsd_committer 2020-05-07 08:37:47 UTC
Created attachment 214223 [details]
auto-generated by clang
Comment 2 Eugene Grosbein freebsd_committer 2020-05-07 08:39:45 UTC
Created attachment 214224 [details]
preprocessed AArch64InstPrinter-5a6d13.cpp (xz-compressed)
Comment 3 Eugene Grosbein freebsd_committer 2020-05-07 08:40:46 UTC
It seems the problem is related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242266 (or same).
Comment 4 Eugene Grosbein freebsd_committer 2020-05-07 08:44:09 UTC
Created attachment 214225 [details]
/etc/src.conf
Comment 5 Eugene Grosbein freebsd_committer 2020-05-07 08:53:36 UTC
Dimitry, please take a look at this.
Comment 6 Eugene Grosbein freebsd_committer 2020-05-07 09:46:52 UTC
As temporary work-around, I update to stable/11 r360655 (5 May 2020 before import of clang-9) instead of tip of stable/11.
Comment 7 Dimitry Andric freebsd_committer 2020-05-07 09:58:13 UTC
Yeah, this looks about the same. I tried installing 11.2-RELEASE which comes with clang version 6.0.0 (tags/RELEASE_600/final 326565), and that gives:

$ /usr/bin/time -l clang -cc1 -triple i386-unknown-freebsd11.2 -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name AArch64InstPrinter.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -dwarf-column-info -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-notes-file /usr/obj/home/src/tmp/home/src/lib/clang/libllvm/Target/AArch64/MCTargetDesc/AArch64InstPrinter.gcno -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D HAVE_VCS_VERSION_INC -D NDEBUG -D LLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.4\" -D LLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.4\" -D DEFAULT_SYSROOT=\"/usr/obj/home/src/tmp\" -D LLVM_TARGET_ENABLE_AARCH64 -D LLVM_TARGET_ENABLE_ARM -D LLVM_TARGET_ENABLE_MIPS -D LLVM_TARGET_ENABLE_POWERPC -D LLVM_TARGET_ENABLE_SPARC -D LLVM_TARGET_ENABLE_X86 -D LLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -D LLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -D LLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -D LLVM_NATIVE_TARGET=LLVMInitializeX86Target -D LLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -D LLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -O2 -Wno-c++11-extensions -std=c++11 -fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fno-rtti -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-loops -vectorize-slp -x c++ AArch64InstPrinter-5a6d13.cpp
      165.43 real        30.21 user        45.18 sys
   3876424  maximum resident set size
     60691  average shared memory size
       436  average unshared data size
       271  average unshared stack size
   4423574  page reclaims
    130240  page faults
         0  swaps
         0  block input operations
         5  block output operations
         0  messages sent
         0  messages received
         0  signals received
    130255  voluntary context switches
       958  involuntary context switches

so it takes ~3.7 GiB and a *long* time to compile, though it does not crash.

With -O1, it takes about 20 seconds and ~250 MiB instead, so I suggest using that for now.
Comment 8 Eugene Grosbein freebsd_committer 2020-05-07 10:08:57 UTC
I don't think that default FreeBSD 11.2/i386 allows userland process to take 3.7GB.

Is it possible to force buildworld to use -O1 for this specific part of bootstrap so it would work "out of the box"?
Comment 9 Dimitry Andric freebsd_committer 2020-05-07 10:43:05 UTC
(In reply to Eugene Grosbein from comment #8)
Hm as a crutch we could add something to llvm.build.mk to lower the optimization level when TOOLS_PREFIX is unset (e.g. when the cross-tools stage is run). @emaste what's your opinion on this?

E.g. adding something like:

.if !defined(TOOLS_PREFIX)
# Lower optimization level to increase probability of successful bootstrap
CFLAGS+= -O1
.endif

That is rather ugly though. I'd rather have people with low-spec systems use CFLAGS=-O1 in their /etc/make.conf or /etc/src.conf, or simply use external toolchains.
Comment 10 Eugene Grosbein freebsd_committer 2020-05-07 10:57:51 UTC
My system is not low-spec.

real memory  = 4294967296 (4096 MB)
avail memory = 3142152192 (2996 MB)

This is very old server installed when FreeBSD/amd64 was not ready for production and updated over time staying i386.

Source upgrade path should work for i386, I believe.
Comment 11 Bob Bishop 2020-05-07 11:09:01 UTC
Is it possible to turn on PAE as a workaround?
Comment 12 Eugene Grosbein freebsd_committer 2020-05-07 11:39:07 UTC
PAE would be much worse "workaround".
Comment 13 Bob Bishop 2020-05-07 13:09:37 UTC
(In reply to Eugene Grosbein from comment #12)
Depends on your point of view. I'm suggesting it in this case, not in gereral. It is  likely to work, and addresses the actual issue rather directly.
Comment 14 Ed Maste freebsd_committer 2020-05-07 17:52:58 UTC
(In reply to Dimitry Andric from comment #9)
Maybe the equivalent of:
.if !defined(TOOLS_PREFIX) && defined(IS_A_32BIT_BUILD_HOST)