Re: Problem with ARM port and pow() function

[Nick Clifton <nickc at redhat dot com>]

Hi Fausto,

> Now I can follow the code step-by-step with insight; I've examined the 
> tan(22.2) function: the execution is regular up to the __ieee754_rem_pio2 
> call inside the tan function. The __ieee754_rem_pio2 function itself is 
> regular too, up to when it calls the fabs() function at line 128; fabs() 
> seems to be executed regularly, but at the return point it doesn't return 
> back to __ieee754_rem_pio2: instead it go to the starting point of the 
> floor() function (with no apparently good reasons...).

floor() follows fabs() in memory.  What has happened is that instead of 
returning from fabs() control has just continued on straight into floor().  You 
need to find out why this has happened.  In the compiled program I am looking 
at, fabs is implemented like this:

00009ad0 <fabs>:
    9ad0:	e92d0070 	push	{r4, r5, r6}
    9ad4:	e3c14102 	bic	r4, r1, #-2147483648	; 0x80000000
    9ad8:	e1a06001 	mov	r6, r1
    9adc:	e1a05000 	mov	r5, r0
    9ae0:	e1a01004 	mov	r1, r4
    9ae4:	e8bd0070 	pop	{r4, r5, r6}
    9ae8:	e12fff1e 	bx	lr
    9aec:	00000000 	andeq	r0, r0, r0

00009af0 <floor>:

So the BX instruction at 9ae8 ought to return to __ieee754_rem_pio2, and the 
only reason it would not is if the LR register has been corrupted.  There is no 
good reason for this to happen, (at least in the code above), so this leads to 
two possibilities:

  1. You have an interrupt that is occurring and corrupting the LR register.

  2. The fabs() function in your program has been assembled differently from
     the version above and there is a compiler bug in the version you have.

Option 2 is the easiest to test for.  What does the fabs() function look like 
in your program ?  Can you spot any compilation problems ?

Cheers
  Nick