[asterisk-dev] Asterisk 13 and -march=native

Steve Murphy murf at parsetree.com
Mon Mar 2 14:50:51 CST 2015


Hello!

Found an interesting problem with Asterisk 13 on a cloud
box running CentOS 6.6. It compiled, but would die with
an illegal instruction on loading. Looking at the result,
I saw that it was dying on the assembler instruction:

vcvtsi2sdq -0x98.....

Apparently, this cloud box is AMD opteron 64-bit, but does
not have that particular opcode supported. I see that every
file compiles with -march=native, and that this can be turned
on/off via the 'BUILD_NATIVE' compiler option in menuselect.

I looked this up in the gcc man page, and for the i386/AMD 64-bit options,
I see (under -mtune):

           native
               This selects the CPU to tune for at compilation time by
determining the
               processor type of the compiling machine.  Using
-mtune=native will
               produce code optimized for the local machine under the
constraints of the
               selected instruction set.  Using -march=native will enable
all
               instruction subsets supported by the local machine (hence
the result
               might not run on different machines).

And, in this case, the code generated didn't even run on my own machine.
Now, I know that one simple solution to this problem is to turn off the
native
compile option in menuselect. (I tried it, and it works).  I tried again,
and  turned it
on,but changed the makefile rules file to use -mtune=native instead, and
this also
worked to solve this crash.

Output of "cat /proc/cpuinfo"

vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD Opteron(TM) Processor 6272
stepping    : 2
cpu MHz        : 2100.096
cache size    : 2048 KB
physical id    : 0
siblings    : 1
core id        : 4
cpu cores    : 1
apicid        : 0
initial apicid    : 4
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht
syscall nx mmxext fxsr_opt lm up rep_good unfair_spinlock pni pclmulqdq
ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm cmp_legacy extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 perfctr_core
perfctr_nb
bogomips    : 4200.19
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management:


On my own AMD powered workstation, I see, in one of my centos 6.6 vm's:

vendor_id    : AuthenticAMD
cpu family    : 6
model        : 6
model name    : QEMU Virtual CPU version 2.0.0
stepping    : 3
...
flags        : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up unfair_spinlock pni
cx16 x2apic popcnt hypervisor lahf_lm svm abm sse4a

Now, I guess I'm suggesting that -mtune=native be used instead of
-march=native, as
it will, by default, yield a working set of code on the current machine, no
matter what
the possible options are, as the BUILD_NATIVE option is turned on by
default (at least
in my environment), and it's not easily recognized when BUILD_NATIVE is
appropriate
and when it is not.  Running on VM's appear to give stripped-down CPU's;
and such
appears to a fad that will not go away soon... But, I'm no expert. Am I
being silly?

murf

-- 

Steve Murphy
ParseTree Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150302/313e0c35/attachment.html>


More information about the asterisk-dev mailing list