Actions

icon Post
text/html Subscribe
text/html Unsubscribe
CodeSourcery > List Archives
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Alan Young <ayoung@xxxxxxxxxxxxxxx>
  • Subject: Re: [arm-gnu] Possible corruption of s20 register with 2009q1-203
  • From: Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>
  • Date: Tue, 2 Feb 2010 10:04:05 -0500
On Tue, Feb 02, 2010 at 11:02:37AM +0100, Alan Young wrote:
>   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.

FYI, the gdbserver included in Sourcery G++ does display the VFP
registers if the kernel is new enough.

>   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.

It should have been saved by callees.  It probably is, if you only see
this problem intermittently.

This symptom is typically caused by a kernel bug, specifically failure
to context switch the VFP registers in some case.  I suggest checking
with your kernel vendor for related patches.  I think someone recently
posted a test program to the ARM kernel list, but I may be thinking of
another problem.

> 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.

We believe that GCC 4.4 is ready for prime time.  If your primary
concern is code size, use -Os instead of -O2; we've made some changes
that increase both performance and code size at -O2.  We plan to
further increase performance and decrease code size over time, of
course.

-- 
Daniel Jacobowitz
CodeSourcery