Trying to debug a program using gdb, it fails reporting SIGILL in OPENSSL_cpuid_setup.
With this simple code I have the same behaviour with :
#include <openssl/ssl.h>
int main()
{
SSL_library_init();
}
It compile and run well but starting with gdb report following backtrace
Program received signal SIGILL, Illegal instruction.
0xb6b2eb40 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) where
#0 0xb6b2eb40 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#1 0xb6b2b404 in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#2 0xb6fdf058 in call_init (l=<optimized out>, argc=1, argv=0xbefff7d4, env=0xbefff7dc) at dl-init.c:78
#3 0xb6fdf134 in _dl_init (main_map=0xb6fff958, argc=1, argv=0xbefff7d4, env=0xbefff7dc) at dl-init.c:126
#4 0xb6fcfda4 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
How can I run such a program under gdb ?
It actually does it all the time, and not just under GDB. It is normal behavior in startup code as the library tests for processor features. You can safely ignore it by issuing
handle SIGILL nostop
.See item 17 in the OpenSSL FAQ for more details: When debugging I observe SIGILL during OpenSSL initialization: why?.
I got the similar situation in BBB. However, if I ignore the signal and continue, the process goes on normally. I'm not sure why, but it seems like the signal can be ignored in this situation.
If you still want to use GDB and debug with it, there is a chance to ignore SIGILLs by GDB with: