Hi,
> I see a very strange bug in crypto/sparcv9cap.c. OpenSSL 1.0.0d checks
> sparc capabilities with SIGILL signal. On sparc64 (both Linux and
> solaris, with UltraSPARC III+ and T1 CPU's), SIGILL handler is called
> and program terminates with SIGILL in _sparcv9_fmadd_probe:
>
> 00000001002a32d0 <_sparcv9_fmadd_probe>:
> 1002a32d0: 81 b0 0d 80 impdep1 108, %f0, %f0, %f0
> 1002a32d4: 85 b0 8d 82 impdep1 108, %f2, %f2, %f2
> 1002a32d8: 81 c3 e0 08 retl
> 1002a32dc: 81 b8 04 40 impdep2 34, %f0, %f0, %f0 <= here
>
> If I add printf() in signal handler, I see that it is called, and that
> siglongjmp() works. With my printf(), my program doesn't abort with
> SIGILL anymore but with SIGBUS (?!).
Could you 'truss -v sigaction,sigprocmask apps/openssl version' and
submit output?
> Modifications :
> static void common_handler(int sig)
> { printf("Signal handler\n"); siglongjmp(common_jmp,sig); }
>
> I don't understand why, with this trivial modification, my program run
> fine (and of course prints "Signal handler" on stdout).
I don't understand. First use say that it fails with SIBUS (instead of
expected SIGILL) and then you say that program runs fine. Could you be
kind to clarify?
> I have seen this bug some months ago (dec 2010) on a sparc T1 running
> Solaris, but I'm not able to remember how I have fixed this trouble...
But do you have binary left? In worst case one (I) can disassemble it
and identify the change... Not that I really understand what's going on,
as I can't reproduce the problem on UltraSPARC-IIe and III...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
