Fwd: Different behaviour of RTEMS in QEMU/i386 and SPARC
Constantine "chicky" Giotopoulos
kotsosgiotopoulos at gmail.com
Mon Oct 31 13:27:47 UTC 2011
If I compile paranoia.c with the -lm option in an Intel machine (outside of
Qemu), I get 1 defect and 1 flaw. One of the two occurs in the point where
Qemu hangs. I would expect a similar behaviour when I execute the same
code on Qemu/i386 using a single RTEMS task, probably with a lot more
If I comment out the specific part of the code, paranoia runs till the
end, producing a lot more defects, flaws, etc (around 11 in total) indeed.
This is expected. It is the hanging that puzzles me and the fact that it
doesn't hang in the previous case (Intel machine), or when
compiling&executing the exact same code in a SPARC machine.
By the way I didn't understand Mr. Joel's comment:
"...since it doesn't happen on real hardware, it is explained as a
deficiency on real hardware."
Is it worth the time debbuging with GDB? Or is it a "known" issue that has
to do i386 or Qemu (or both?) ?
On Mon, Oct 31, 2011 at 1:17 PM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> If I compile paranoia.c with
> gcc -O2 -m32 -mfpmath=387 paranoia.c -lm
> then I get this
> The number of FAILUREs encountered = 4.
> The number of SERIOUS DEFECTs discovered = 4.
> The number of DEFECTs discovered = 3.
> The number of FLAWs discovered = 2.
> In case you floating point operations are not fully IEEE 754 conform the
> paranoia program my hang in infinite loops.
> Sebastian Huber, embedded brains GmbH
> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> Phone : +49 89 18 90 80 79-6
> Fax : +49 89 18 90 80 79-9
> E-Mail : sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> rtems-users mailing list
> rtems-users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users