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 <[email protected]>
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 
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto


-- 
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to