[yocto] Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64
-mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I.
-I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pipe -c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H
-I. -I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pipe -c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge <christrobridge at hotmail.com
> wrote:

> This arose building asterisk switching from 13.7 to 13.11+.
>
>
> The executable core dumps immediately with an illegal instruction
> instruction, which gdb reported as 'andn'.  This is part of BMI1, which
> was introduced with Haswell.  I am targeting a (32-bit) Z5xx Atom
> processor, which predates this instruction.
>
>
> I don't know what changed in the Asterisk build to cause this (the
> instruction is in some regular compiler generate code) but the compiler is
> still generating legal core2 code and tune-core2.inc is recommended for
> Atom processors:
>
>
> "This tune is recommended for the Intel Core 2 CPU family, including
> Conroe, Merom and beyond, as well as the first Atom CPUs, Diamondville,
> and beyond."
>
>
> I am still considering this output is down to some quirk in my
> configuration but I found that -mtune and -march options were added for
> Atom in GCC in 4.5, so this could be another line of attack, although I
> didn't find any explicit code for this in meta/meta-intel.
>
>
> Any ideas?
>
>
> My initial plan is to try to acoid the core2 tuning and then, if that
> helps, attempt to get atom tuning working, unless that's likely to be cause
> further breakages due to being unexpected.
>
>
> Regards,
>
> Chris
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170116/7af2b4d6/attachment.html>