Re: trouble with netbsd-8 on RPI3?

[Greg Troxel <gdt%lexort.com@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) writes:

> gdt%lexort.com@localhost (Greg Troxel) writes:
>
>>(gdb) run -f -d 2 -u named -t /var/chroot/named
>>Starting program: /usr/sbin/named -f -d 2 -u named -t /var/chroot/named
>
>>Program received signal SIGILL, Illegal instruction.
>>0x652b3bc8 in _armv8_pmull_probe () from /usr/lib/libcrypto.so.12
>
> That's not a bug. libcrypto just probes the CPU capabilities and catches
> the SIGILL. Since the debugger catches SIGILL first you need to resume
> the process with 'cont'.

Thanks.  Now this has come back to me from my last problem.  Continuing,
I get another SIGILL in pthread.


(gdb) run -f -d 2 -u named -t /var/chroot/named
Starting program: /usr/sbin/named -f -d 2 -u named -t /var/chroot/named

Program received signal SIGILL, Illegal instruction.
0x6d953bc8 in _armv8_pmull_probe () from /usr/lib/libcrypto.so.12
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x6d953bb0 in _armv8_aes_probe () from /usr/lib/libcrypto.so.12
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x6d953bb8 in _armv8_sha1_probe () from /usr/lib/libcrypto.so.12
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x6d953bc0 in _armv8_sha256_probe () from /usr/lib/libcrypto.so.12
(gdb) c
Continuing.
[New LWP 2]
[New LWP 4]
[New LWP 7]
[New LWP 6]
[New LWP 5]
[New LWP 3]

Thread 3 received signal SIGILL, Illegal instruction.
[Switching to LWP 4]
0x6dd97d00 in ?? () from /usr/lib/libpthread.so.1
(gdb) bt
#0  0x6dd97d00 in ?? () from /usr/lib/libpthread.so.1
#1  0x6dd97d64 in ?? () from /usr/lib/libpthread.so.1
#2  0x6dd980c8 in ?? () from /usr/lib/libpthread.so.1
#3  0x6dd99b38 in pthread_cond_timedwait () from /usr/lib/libpthread.so.1
#4  0x6de02448 in ?? () from /usr/lib/libisc.so.8
#5  0x6dd9bb0c in ?? () from /usr/lib/libpthread.so.1
#6  0x6d752980 in __mknod50 () from /usr/lib/libc.so.12
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/i 0x6dd97d00
=> 0x6dd97d00:  wfe
(gdb)