Different behaviour of RTEMS in QEMU/i386 and SPARC

Joel Sherrill joel.sherrill at OARcorp.com
Mon Oct 31 11:57:42 UTC 2011

I don't remember this discussion either.

The intent of including paranoia was to have something that exercised the fpu. If it reports issues, they may indicate an unhandled exception, fpu issue (hw, sw emulation or simulator) or a deficiency with paranoia. 

In this case, you could attach gdb and see what's happening but since it doesn't happen on real hardware, it is explained as a deficiency on real hardware.


Ralf Corsepius <ralf.corsepius at rtems.org> wrote:

>On 10/31/2011 11:49 AM, Sebastian Huber wrote:
>> On 10/31/2011 11:41 AM, Ralf Corsepius wrote:
>>> Apart of this, RTEMS's paranoia's results should not be taken too
>>> seriously.
>>> The code is known to be questionable.
>>> Several years ago, several people, who can be considered very
>>> knowledgable
>>> about the detail being involved ]1], had recommended RTEMS to drop
>>> this paranoia.
>> It would be nice if someone can remember this discussion and provide a
>> link to the archives.
>Unfortunately, I don't. A brief google search also did not provide much 
>clues. It was on some GCC related list (or GCC's bugzilla).
>IIRC, an RTEMS user had reported RTEMS paranoia was not providing the 
>expected results. When reporting this issue, some GCC devs stepped in 
>and begun tearing paranoia apart.
>  Answers were along the lines of "bad, outdated code", "non-portable", 
>"invalid testcase". The outcome had been "works sufficiently well for 
>RTEMS in many cases".
>Also, I could bet, Joel had been involved.
>rtems-users mailing list
>rtems-users at rtems.org

More information about the users mailing list