12.0 installworld core dumping on me

Lorenzo Salvadore phascolarctos at protonmail.ch
Tue Apr 23 20:43:52 UTC 2019

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday 23 April 2019 20:36, Bob Willcox <bob at immure.com> wrote:

> On Tue, Apr 23, 2019 at 07:51:34AM -0500, Bob Willcox wrote:
> > I installed the 20190418 12.0-STABLE snapshot and then checking out the latest 12.0-STABLE source code
> > and performing a 'make buildworld' when I attempt to do a 'make installworld' I get this:
> > root at darth:3 /usr/src> make installworld
> > make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using cached toolchain metadata from build at darth.immure.com on Mon Apr 22 19:54:57 CDT 2019
> > Illegal instruction (core dumped)
> > rescue/sh check failed, installation aborted
> > *** Error code 1
> > Stop.
> > make[1]: stopped in /usr/src
> > *** Error code 1
> > Stop.
> > make: stopped in /usr/src
> > This leaves me with a rescue.core file in the /usr/obj/usr/src/amd64.amd64 directory.
> > The toolchain-metadata.mk file contains this:
> > .info Using cached toolchain metadata from build at darth.immure.com on Mon Apr 22 19:54:57 CDT 2019
> > COMPILER_FEATURES= c++11 retpoline
> > X_COMPILER_FEATURES= c++11 retpoline
> > LINKER_FEATURES= build-id ifunc filter retpoline
> > X_LINKER_FEATURES= build-id ifunc filter retpoline
> > LINKER_FREEBSD_VERSION=356365-1200007
> > X_LINKER_FREEBSD_VERSION=356365-1200007
> > Anyone have any idea on what might be the cause or how best to proceed with debugging this?
> > Thanks,
> > Bob
> Well, it turns out that the following line that I placed in the system's
> make.conf file was the culprit:
> CPUTYPE?= skx
> Removing it and rebuilding world allowed 'make installworld' to run. I had
> just tried that on a lark since the CPU is an I7-9700k which is a Coffee Lake
> processor and is newaer than Skylake so I thought...what the heck, give it a
> try. Bad idea.
> The compiler must be generating instructions that aren't compatible with my
> CPU. Removal of that line in make.conf seems to have gotten me fixed. :)
> Bob

I am playing too with CPUTYPE in these days. I think I will soon write a wiki page
about that. Here is a short description of what I have found out.

What I suggest you to do, if you still want to play with CPU_TYPE (I do not recommend it:
I cannot see any real improvement), is to set CPUTYPE?= native. Then look into
/usr/share/mk/bsd.cpu.mk what feature you can enable or disable for your processor:
avx, sse3 etc. Compare this list with the feature supported by your processor (run
"dmesg | head -n 25" to get them) and define MACHINE_CPU+= with what you need
(some features probably are already set: check them with "make -V MACHINE_CPU").

Reading /usr/share/mk/bsd.cpu.mk you will see some values you can give to CPUTYPE
that will set automatically MACHINE_CPU to the right value. However I discourage you
from using them: in my case, I should set CPU_TYPE?=ivybridge, however bsd.cpu.mk,
clang and gcc all believe that ivybridge support avx, but this is wrong at least for my
cpu, thus I get invalid instructions (even if I correct bsd.cpu.mk), while everything is
fine by setting CPU_TYPE?=native.
If, however, you still want to set your specific model instead of native into CPU_TYPE,
you can get the supposed right value running
"cc -v -x c -E -march=native /dev/null -o /dev/null" or "llvm-tblgen -version".

If you happen to encounter some invalid instructions with some port, recompile it
with NO_CPU_CFLAGS=yes: this will avoid setting -march=<CPU_TYPE> in
your CFLAGS.
I had to do that with ports involving rust.

Lorenzo Salvadore.

More information about the freebsd-stable mailing list