On 2015/05/19 22:02, Masanobu SAITOH wrote:
Hi.
On 2015/05/19 10:45, Timo Buhrmester wrote:
As of late, when building (and installing) -head I end up with a libcrypto
causing SIGILL, apparently due to using the ``pshufb'' instruction (which I
believe is part of the SSE3 extension).
My CPU is, according to /proc/cpuinfo:
For x86, /proc/cpuinfo have not maintained for many years...
To avoid this problem, use "cpuctl identify 0" instead of /proc/cpuinfo
to check cpu features (PR#49246).
Regards.
I've commit the change of x86/procfs_machdep.c to print much information about
CPU features now!
Example:
before:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 12
model name : Intel(R) Xeon(R) CPU E3-1240L v3 @ 2.00GHz
stepping : 3
cpu MHz : 2000.24
fdiv_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
after:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 12
model name : Intel(R) Xeon(R) CPU E3-1240L v3 @ 2.00GHz
stepping : 3
cpu MHz : 2000.27
fdiv_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2
erms invpcid rtm
It's not perfect but it's better than before
Thanks.
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 6
model name : AMD Athlon(tm) II X2 265 Processor
stepping : 3
cpu MHz : 3311.46
fdiv_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht
processor : 1
[another core]
(No sse3)
As far as gdb is concerned, in libcrypto.so.8.4, this is the point where it
blows up:
[...]
>0x7f7ff6f3ba87 pshufb %xmm6,%xmm0 ;bang
0x7f7ff6f3ba8c add $0x40,%r9 ;for context
0x7f7ff6f3ba90 pshufb %xmm6,%xmm1
0x7f7ff6f3ba95 pshufb %xmm6,%xmm2
0x7f7ff6f3ba9a pshufb %xmm6,%xmm3
0x7f7ff6f3ba9f paddd %xmm9,%xmm0
(Core dump available on request)
The assembly code originates from
crypto/external/bsd/openssl/dist/crypto/sha/asm/sha1-x86_64.pl (around line
346), but seems to have been untouched for too long to be the culprit (a -head
build in March didn't provoke the problem yet).
Any ideas?
--
-----------------------------------------------
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)