Illegal Instruction Generate for Intel Atom

Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 2318 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

[-- Attachment #1: Type: text/plain, Size: 3198 bytes --]

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@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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 4622 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]

Thanks Leon,


I agree it is probably an unrelated coincidence.  I am also using morty.


I don't have the logs around any more but the logs had -march=core2 -mtune-core2 -m32, which was correct for the build.  I did wonder whether the asterisk autoconf was too clever but I think in my case it may be more a case of the compiler using core2 instructions that are not valid for atom.

Regards,
Chris
________________________________
From: Leon Woestenberg <leon@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@hotmail.com<mailto:christrobridge@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@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 6146 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 4436 bytes --]

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@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@hotmail.com<mailto:christrobridge@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@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 7072 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

Hi Chris,

there is a hint here how you can find out what gcc is actually using; you
could try with and without the -march=native:

http://en.chys.info/2010/04/what-exactly-marchnative-means/

On Mon, Jan 16, 2017 at 3:47 PM, Chris Trobridge <christrobridge@hotmail.com
> wrote:

> the initial args are "-m32 -march=i586" but there is "-march=native"
> appended to the end of the line.
>

Regards,

Leon.

[-- Attachment #2: Type: text/html, Size: 1032 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On 16 January 2017 at 14:47, Chris Trobridge <christrobridge@hotmail.com>
wrote:

> 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.
>
>
Looks like asterisk itself is adding -march=native, so you'll need to dig
through it's makefiles and work out how to disable it (or just delete them).

Ross

[-- Attachment #2: Type: text/html, Size: 822 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

+Khem

On Mon, Jan 16, 2017 at 4:40 PM, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 16 January 2017 at 14:47, Chris Trobridge <christrobridge@hotmail.com>
> wrote:
>
>> 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.
>>
>> Looks like asterisk itself is adding -march=native, so you'll need to dig
> through it's makefiles and work out how to disable it (or just delete them).
>
> Ross
>

That makes me wonder what are the exact rules of processing the command
line options by GCC.

I thought the precedence is:  TUNE >= CPU >= ARCH.

But apparently, multi -march= definitions, is not well defined, or is it?

There is an unanswered similar question here:
https://lists.debian.org/debian-gcc/2015/12/msg00153.html

Regards,

Leon.

[-- Attachment #2: Type: text/html, Size: 2069 bytes --]

Re: Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Thanks Ross,


I came to that conclusion too, and changes to the asterisk build system was really always the most likely source of the problem.  On the plus side, I have learned a lot more about machine/processor configuration in the bsp layers pursuing that dead end.


I went back through the asterisk change notes and at some point in the past they decided to use -march=native as a means to produce the best optimised code, while still retaining the option to disable this.


There are some more notes from last summer about changing how this is configured, and it certainly defaults to enabled since then.  BUILD_NATIVE is an option in their 'menuselect' so I need to configure that, as the clean solution, rather than just patching their makeopts.


Regards,

Chris

________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: 16 January 2017 15:40
To: Chris Trobridge
Cc: Leon Woestenberg; Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom


On 16 January 2017 at 14:47, Chris Trobridge <christrobridge@hotmail.com<mailto:christrobridge@hotmail.com>> wrote:

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.

Looks like asterisk itself is adding -march=native, so you'll need to dig through it's makefiles and work out how to disable it (or just delete them).

Ross

[-- Attachment #2: Type: text/html, Size: 2758 bytes --]