This is a discussion on Re: PPC bn_div_words routine rewrite - Openssl ; > Let's take first call to BN_div_word for example from BN_bn2dec, the > parameter being passed to BN_div_word is (a=35, w=1000000000) (decimal > numbers). It then calls the bn_div_words with (h=0, l=35, > d=1000000000) if you examine the code in ...
> Let's take first call to BN_div_word for example from BN_bn2dec, the
> parameter being passed to BN_div_word is (a=35, w=1000000000) (decimal
> numbers). It then calls the bn_div_words with (h=0, l=35,
> d=1000000000) if you examine the code in linux_ppc32.s it will exit
> early on because h is 0. the routine returns a divide by 0, which is
> undefined according to the manual. In the case of ppc8xx the result
> is 0x80000000.
And on the PPC machine I have access to it returns 0. This is
explanation why I never experienced any SEGV, but a sparse decimal
output. And it does explain why BN_is_zero condition never met on your
system and you hit sbrk(0) limit and suffer the penalty. However! Note
that updated routine,
issues divide by 0 [it traps instead, but the condition is never met now
when called from BN_div_words] and it does return correct answer to me.
Can you really confirm that updated subroutine doesn't work for you? And
if so, how does problem manifest? Still SEGV? At same point?
It should pointed out that bug in ppc.pl is encountered only in 0.9.7
context, as 0.9.8 avoids it by normalizing divisor [and adjusting
dividend accordingly]. BTW, I can confirm that 0.9.7 produces correct
decimal ASCII with your routine [but no luck with make test_bn], but in
0.9.8 context decimal printout comes out truncated [not sparse with some
significant digits there and there, but truncated] if your routine is
pasted in. A.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com