Date: Tue, 23 Apr 2019 20:43:34 +0000 From: Lorenzo Salvadore <phascolarctos@protonmail.ch> To: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: 12.0 installworld core dumping on me Message-ID: <VY5IVXkeYqjAiEfioKjBj3VOk6dV13_mlTIWo1NCenI8KJZyEGp70nJzsZqknw8c-BjXI6RlICv3lL71vZ-V-iQ4l03px0useGS69QA5svI=@protonmail.ch> In-Reply-To: <20190423183604.GL6607@rancor.immure.com> References: <20190423125133.GG3392@rancor.immure.com> <20190423183604.GL6607@rancor.immure.com>
next in thread | previous in thread | raw e-mail | index | archive | help
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday 23 April 2019 20:36, Bob Willcox <bob@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 install= world' I get this: > > root@darth:3 /usr/src> make installworld > > make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: U= sing 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.am= d64 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 > > _LOADED_TOOLCHAIN_METADATA=3Dt > > COMPILER_VERSION=3D80000 > > X_COMPILER_VERSION=3D80000 > > COMPILER_TYPE=3Dclang > > X_COMPILER_TYPE=3Dclang > > COMPILER_FEATURES=3D c++11 retpoline > > X_COMPILER_FEATURES=3D c++11 retpoline > > COMPILER_FREEBSD_VERSION=3D1200018 > > X_COMPILER_FREEBSD_VERSION=3D1200018 > > LINKER_VERSION=3D80000 > > X_LINKER_VERSION=3D80000 > > LINKER_FEATURES=3D build-id ifunc filter retpoline > > X_LINKER_FEATURES=3D build-id ifunc filter retpoline > > LINKER_TYPE=3Dlld > > X_LINKER_TYPE=3Dlld > > LINKER_FREEBSD_VERSION=3D356365-1200007 > > X_LINKER_FREEBSD_VERSION=3D356365-1200007 > > .export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES COMPILER_FREEB= SD_VERSION LINKER_VERSION LINKER_FEATURES LINKER_TYPE LINKER_FREEBSD_VERSIO= N > > .export X_COMPILER_VERSION X_COMPILER_TYPE X_COMPILER_FEATURES X_COMPIL= ER_FREEBSD_VERSION X_LINKER_VERSION X_LINKER_FEATURES X_LINKER_TYPE X_LINKE= R_FREEBSD_VERSION > > 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?=3D skx > > Removing it and rebuilding world allowed 'make installworld' to run. I ha= d > 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 i= t 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 wi= ki 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?=3D native. Then look= into /usr/share/mk/bsd.cpu.mk what feature you can enable or disable for your pr= ocessor: avx, sse3 etc. Compare this list with the feature supported by your process= or (run "dmesg | head -n 25" to get them) and define MACHINE_CPU+=3D with what you = need (some features probably are already set: check them with "make -V MACHINE_C= PU"). Reading /usr/share/mk/bsd.cpu.mk you will see some values you can give to C= PUTYPE that will set automatically MACHINE_CPU to the right value. However I disco= urage you from using them: in my case, I should set CPU_TYPE?=3Divybridge, however bs= d.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?=3Dnative. If, however, you still want to set your specific model instead of native in= to CPU_TYPE, you can get the supposed right value running "cc -v -x c -E -march=3Dnative /dev/null -o /dev/null" or "llvm-tblgen -ver= sion". If you happen to encounter some invalid instructions with some port, recomp= ile it with NO_CPU_CFLAGS=3Dyes: this will avoid setting -march=3D<CPU_TYPE> in your CFLAGS. I had to do that with ports involving rust. Lorenzo Salvadore.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?VY5IVXkeYqjAiEfioKjBj3VOk6dV13_mlTIWo1NCenI8KJZyEGp70nJzsZqknw8c-BjXI6RlICv3lL71vZ-V-iQ4l03px0useGS69QA5svI=>