[yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Ok,


Rebuilt system the for i586 and asterisk is still the one program to fail, still with that illegal andn instruction.  So I can rule out the core2 tuning.


The compiler log is next to useless, as the asterisk build hides the command lines but the makeopts files has the following, which seems fair enough:


CC=i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/chris/yocto/build/tmp/sysroots/pokini
HOST_CC=cc
BUILD_CC=cc
CXX=i586-poky-linux-g++  -m32 -march=i586 --sysroot=/home/chris/yocto/build/tmp/sysroots/pokini

Looking around the web, this illegal andn instruction has come up before - possibly to do with using 'native' tuning.  This is over a long period of time though, so not very helpful.


Managed to get the actual compiler lines and the initial args are "-m32 -march=i586" but there is "-march=native" appended to the end of the line.


As noted previously , there have been various issues reported with march=native, for a very long time, so I will try to see how to get that removed from the build.


Chris


________________________________
From: Leon Woestenberg <leon at sidebranch.com>
Sent: 16 January 2017 09:57
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom

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<mailto: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<mailto: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/e8b125bc/attachment.html>