Re: vfp exception issues with freepascal
On Sat, 2012-07-28 at 16:42 +0100, peter green wrote:
> I am involved in a project called raspbian to produce a hard-float
> derivative of debian for the raspberry pi. Within this port we had
> problems with floating point exceptions while running the compiler.
> These problems were tracked down by masta (a freepascal upstream
> developer) to reversed logic in a routine for controlling floating point
> exception settings (attempting to disable an exception enabled it and
> Howevr this then left the question of "why didn't I see this problem
> when preparing the freepascal packages for debian armhf?". The
> conclusion i've come to is that on the armv7 systems i've tested (a
> beagleboard XM running 18.104.22.168-x2 and an IMX53 quickstart board running
> ) the method freepascal uses for enabling vfp exceptions simply doesn't
> I've written a small test program in C and inline assembler to
> demonstrate this. It tries to enable a number of floating point
> exceptions using a price of inline assembly I copied from the freepascal
> run time library and then does a division of the command line arguments.
> When I test this on a Pi running raspbian I get a floating point
> exception as expected.
> root@raspbian:~# ./a.out 1 0
> Floating point exception
> but when I try it on my beagleboard XM or IMX53 board I don't get any
> root@plugwash:/home/plugwash# ./a.out 1 0
> Any vfp experts able to help get to the bottom of what is going on here?
I quote: "ARM VFPv3 and VFPv4 do not support trapping floating-point
VFPv2, VFPv3U and VFPv4U do. The lack of support causes the glibc
math/test-fenv test to fail on VFPv3 and VFPv4 systems.
The natural fix for that would be for fesetenv (FE_NOMASK_ENV) to fail
hardware not supporting trapping exceptions. There is, however, no
bit to indicate whether trapping floating-point exceptions is
Could one be added to the kernel, or is there a good way fesetenv could
detect this from userspace without a new HWCAP bit?"