Unexpected trap(0 x4) ... fp disabled

[Eric Norum]

1) Floating point exceptions on many architectures can be fairly imprecise.   Could the offending code be back a line or two?
2) There's always the possibility that a runaway pointer or bad array index has resulting in your code being mangled.   Can you use a debugger to check that the instructions which you expect to be around that address are indeed still there?

On Jun 23, 2010, at 10:07 AM, Gardner, Michael T wrote:

> I am running a test program on a leon3 using rtems 4.10.  When the program executes a standard “read()” call I see the following error message and RTEMS and the program terminate abnormally:
> Unexpected trap (0x 4) at address 0x40006710                                           
> fp disabled
>  
> The offending source line of code is (all arguments are valid):
> *bytes_read = read(fd, the_packet, max_read_size);
>  
> I have tried compiling my source code both with and without the –msoft-float compiler flag but it crashes each time.  There are some external libraries that are not compiled with the –msoft-float option that are linked into the code.  Could this be contributing to the problem?  I am using the POSIX API with RTEMS and therefore believe that all of my threads are floating point threads. (ref: RTEMS Wiki – Floating Point Support).
>  
> I have looked at previous posts and the RTEMS Wiki for answers regarding this issue, but am still somewhat confused about what I need to do (I’m an RTEMS newbie).  In the Wiki there is a section entitled “Escaping Disaster” in which several options are provided.  Our application needs to use the hardware FPU and the second option seems to be the option that is most applicable.  Does anyone have experience with implementing this option?  What lessons learned can be passed on to make this as painless as possible?
>  
> Michael T. Gardner 
> Sandia National Labs 
> mtgardn at sandia.gov 
> 505-844-1299

-- 
Eric Norum
wenorum at lbl.gov

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