Re: PPC bn_div_words routine rewrite

[Andy Polyakov <appro@fy.chalmers.se>]

> 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, 
http://cvs.openssl.org/getfile/openssl/crypto/bn/asm/ppc.pl?v=1.4 never 
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.