Unexpected trap(0 x4) ... fp disabled

[Gardner, Michael T]

Jiri,

Here is the disassembled code at the 0x40006710 address:

400066e8:       10 80 00 10     b  40006728 <_ZN16GaislerInterfaceD1Ev+0xc4>
400066ec:       01 00 00 00     nop
400066f0:       f0 27 bf f0     st  %i0, [ %fp + -16 ]
400066f4:       82 10 00 19     mov  %i1, %g1
400066f8:       a2 10 00 01     mov  %g1, %l1
400066fc:       e0 07 bf f0     ld  [ %fp + -16 ], %l0
40006700:       c2 07 a0 44     ld  [ %fp + 0x44 ], %g1
40006704:       c2 27 bf f4     st  %g1, [ %fp + -12 ]
40006708:       d0 07 bf f4     ld  [ %fp + -12 ], %o0
4000670c:       40 00 00 8d     call  40006940 <_ZN17HardwareInterfaceD2Ev>
40006710:       01 00 00 00     nop
40006714:       e0 27 bf f0     st  %l0, [ %fp + -16 ]
40006718:       82 10 00 11     mov  %l1, %g1
4000671c:       d0 07 bf f0     ld  [ %fp + -16 ], %o0
40006720:       40 01 84 73     call  400678ec <_Unwind_Resume>
40006724:       01 00 00 00     nop
40006728:       d0 07 a0 44     ld  [ %fp + 0x44 ], %o0
4000672c:       40 01 5d 18     call  4005db8c <_ZdlPv>
40006730:       01 00 00 00     nop
40006734:       81 e8 00 00     restore
40006738:       81 c3 e0 08     retl
4000673c:       01 00 00 00     nop

The code is autogenerated from our model driven development tool called Rhapsody.  I have configured the eclipse project to call the auto-generated makefile, which is probably a little different that building the project using the eclipse plug-in.  I have included in the makefile the -msoft-float option but this has not made any difference.  The code still crashes.  BTW, there is another developer using essentially the same process to generate and build his code with Rhapsody.  He also compiles with the Rhapsody makefile.  His test program worked but mine failed.  The telling difference between the two programs is that his does not use any floating point variables where mine does.  As a test, I included a simple declaration of a double and printed out the value.  This two line change now causes his program to crash with the same error.  So the error really is tied to floating point operations.


Michael T. Gardner
Sandia National Labs
mtgardn at sandia.gov
505-844-1299



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100623/657ab2b9/attachment-0001.html>