[opensuse-arm] openssl armv7_neon_probe fault
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I got a working image for raspberry pi: http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20120730.img... But after running zypper up, zypper broke because with armv6, I get an illegal instruction with recent libopenssl-1.0.1c-1.2 # gdb /usr/bin/zypper GNU gdb (GDB) SUSE (7.4.50.20120603-1.1) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv5tel-suse-linux". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/zypper...(no debugging symbols found)...done. (gdb) run ref Starting program: /usr/bin/zypper ref [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x40c77540 in _armv7_neon_probe () from /lib/libcrypto.so.1.0.0 Missing separate debuginfos, use: zypper install zypper-debuginfo-1.7.0-3.1.armv5tel (gdb) bt #0 0x40c77540 in _armv7_neon_probe () from /lib/libcrypto.so.1.0.0 #1 0x40c73f60 in OPENSSL_cpuid_setup () from /lib/libcrypto.so.1.0.0 #2 0x4000f6e4 in call_init () from /lib/ld-linux.so.3 #3 0x4000f7a8 in _dl_init_internal () from /lib/ld-linux.so.3 #4 0x40000da4 in _dl_start_user () from /lib/ld-linux.so.3 #5 0x40000da4 in _dl_start_user () from /lib/ld-linux.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) It seems others had this problem on archlinux, too. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAWV2oACgkQSTYLOx37oWSJ/wCg9+260RmMhm8hPjc1jHFVlbBP UKAAn0MYoJEuwPLFcG+B95XNBQhVrIuA =smIG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 30.07.2012, at 11:44, Bernhard M. Wiedemann wrote:
Hi,
I got a working image for raspberry pi: http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20120730.img...
But after running zypper up, zypper broke because with armv6, I get an illegal instruction with recent libopenssl-1.0.1c-1.2
# gdb /usr/bin/zypper GNU gdb (GDB) SUSE (7.4.50.20120603-1.1) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv5tel-suse-linux". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/zypper...(no debugging symbols found)...done. (gdb) run ref Starting program: /usr/bin/zypper ref [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction. 0x40c77540 in _armv7_neon_probe () from /lib/libcrypto.so.1.0.0 Missing separate debuginfos, use: zypper install zypper-debuginfo-1.7.0-3.1.armv5tel (gdb) bt #0 0x40c77540 in _armv7_neon_probe () from /lib/libcrypto.so.1.0.0 #1 0x40c73f60 in OPENSSL_cpuid_setup () from /lib/libcrypto.so.1.0.0 #2 0x4000f6e4 in call_init () from /lib/ld-linux.so.3 #3 0x4000f7a8 in _dl_init_internal () from /lib/ld-linux.so.3 #4 0x40000da4 in _dl_start_user () from /lib/ld-linux.so.3 #5 0x40000da4 in _dl_start_user () from /lib/ld-linux.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It seems others had this problem on archlinux, too.
Well, there are 2 issues I can guess from here: 1) armv5 devices don't have neon, so the plugin really doesn't need to be built in the first place, though it shouldn't hurt 2) not all armv7 devices have neon either, so the plugin definitely should catch a SIGILL or properly probe if neon is available Probing neon is fairly trivial. IIRC it's passed in as part of auxv. Maybe the module is really just missing a check? Or it compiles its own check with neon already, which would be a serious bummer :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Monday 30 July 2012, Alexander Graf wrote:
1) armv5 devices don't have neon, so the plugin really doesn't need to be built in the first place, though it shouldn't hurt 2) not all armv7 devices have neon either, so the plugin definitely should catch a SIGILL or properly probe if neon is available
it is in the generic code path,s o executed by all arm platforms. I think the problem is that we do not handle sigsetjmp/longjmp properly. Overall the C code looks like it would catch SIGILL properly (it does that to detect neon support). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Bernhard M. Wiedemann -
Dirk Müller