[arm-gnu] Possible corruption of s20 register with 2009q1-203

[Alan Young <ayoung@xxxxxxxxxxxxxxx>]

Hello,

I have been trying to track down a memory corruption problem for a 
couple of months now, I believe that I have isolated it to a particular 
C function. This is running on a Freescale i.MX35 ARM11 with VFP.

The problem is difficult to track down in part because it can take 
several hours of repeatedly running a test case before the problem 
manifests itself. I find this rather odd as I would expect the data 
being manipulated for this test case to be deterministic and repeatable, 
so altogether I am not completely sure of my analysis.

  1. The function in question derives a local variable from a parameter
     (1 << param).
  2. Checking with gdb I can see that the passed parameter has the
     expected value (8). I check this by noting that the calling
     routine loads the parameter from a stack-pointer-relative address,
     and I can check this location in gdb using the SP value reported
     for the calling frame.
  3. The called function stores the derived value in s20. It should
     have the value 256. At various places throughout the function it
     copies from s20 into a normal working register. Other than this it
     makes no other use of s20, and makes no use at all of d10. I
     cannot inspect s20 directly as gdb is not capable.
  4. Towards the end of the function it uses the value from s20 to
     derive two other local variables which are then used as
     loop-control variables. From inspection of the registers holding
     these derived values, and of others that are dependent on them, it
     appears clear that s20 does not hold (no longer holds?) the
     expected value (256) but instead holds the value 1024.
  5. Between the start of the function and the problem area, calls have
     been made to sin() and cos(). By disassembly of the shared library
     objects I can at least see the possibility of s20 being used
     indirectly by these library routines without having first been saved.

Any observations or suggestions would be welcome.

By compilation with -O0 (usually, I use -O2) of just the source module 
in question, I can eliminate use of s20. I am currently testing the 
results of this.

I have tried a build with 2009q3 (at -O2). It ran successfully for 
several days. By inspection of the disassembly I see that this build is 
not using s20. However, the code-size generated by 2009q3 is at least 
15% larger and other reports (for example, 
http://hardwarebug.org/2010/01/15/arm-compiler-update/) suggest that GCC 
4.4 is not ready for prime time.