Crash under sparc/rtems-4.11 when compiling with FPU

Jiri Gaisler jiri at gaisler.se
Tue Feb 9 12:16:21 UTC 2016



On 09/02/16 12:06, Athanasios.Tsiodras at esa.int wrote:
> Thanks Jiri - I will try that too when I find time.
>
> For now I can report that all the tests I did with the BSPs'.cfg files
> missing the "-msoft-float" seem to work fine - including projects with
> more than 30 threads, with many of them doing native FPU calculations.
> Also, a quick and dirty test - not a proof, but a good indication -
> shows no FPU registers accessed by librtemsbsp.a:
>
>     $ cd /opt/rtems-4.11/sparc-rtems4.11/leon3/lib/
>     $ sparc-rtems4.11-objdump -S librtemsbsp.a | grep '%f[^p]'
>      1f8:   c1 29 a0 04     st  %fsr, [ %g6 + 4 ]
>
> (i.e. searching for %f1, %f2, etc - but not %fp)
>
> Will keep testing!
> Thanassis.

I think that Daniel Hellström from Gaisler had a simple test in C that
would emit an FPU instruction for integer code if the compiler had this
deficiency. I can't find it back though, if Daniel is on this list then
maybe he can post it.

Jiri.

>
>
> *European Space Agency (via HE Space)*
> Thanassis Tsiodras
> Real-time Embedded Software Engineer
> System, Software and Technology Department
>
> *ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands
> Athanasios.Tsiodras at esa.int | www.esa.int
> T +31 71 565 5332
>
>
>
> From:        "Jiri Gaisler" <jiri at gaisler.se>
> To:        Athanasios.Tsiodras at esa.int, "RTEMS List" <users at rtems.org>
> Date:        08/02/2016 19:56
> Subject:        Re: Crash under sparc/rtems-4.11 when compiling with FPU
> ------------------------------------------------------------------------
>
>
>
>
>
> On 08/02/16 13:25, _Athanasios.Tsiodras at esa.int_
> <mailto:Athanasios.Tsiodras at esa.int>wrote:
> Hi Jiri.
>
> My understanding from reading the "Disaster Strikes" section of the
> FPU page
> (_https://devel.rtems.org/wiki/TBR/UserManual/Floating_Point_Support_)
> is that
> at some point the leon3.cfg was switched to "-msoft-float" to avoid
> spurious generation
> of FPU instructions in the kernel by GCC.
>
> But as you can see in my original bug report, this ends up meaning
> that we can't use
> the native FPU **at all** - attempting to compile application code
> *without* -msoft-float
> leads to the crash in newlib that I reported.
>
> My report includes all the steps needed to reproduce the issue - do
> you see anything
> wrong in the set of commands I used to build RSB or RTEMS or the sample?
>
> Your latest answer seems to imply that if I remove the "-msoft-float"
> from leon3.cfg, then
> I can't, in fact use the Leon3 BSP. If that is the case, then how can
> I build a native-FPU-using
> version of anything?
>
> My solution to this would be to set SPARC_HAS_FPU = 1 permanently in
> score/cpu/sparc/rtems/score/sparc.h and use -msoft-float in leon3.cfg
> (and all other sparc bsps). This will add FPU context support to the
> kernel, and make sure no spurious FPU instructions are emitted. You
> application need to be partitioned such that all code running in
> non-FPU threads can be compiled with -msoft-float and all code called
> from FPU threads are compiled without -msoft-float. During the final
> link, -msoft-float must not be used so the correct libm is pulled in
> (if needed). You will also need to check that other newlib libraries
> such as libc don't have spurious FPU instructions.
>
> But maybe all this is unnecessary now - does anybody actually know if
> the latest gcc version still have this behavior? I might be worthwhile
> to check before we start messing with the kernel code...
>
> Jiri.
>
>
>
>
> Thanks in advance and Kind regards,
> Thanassis.
> *
> European Space Agency (via HE Space)*
> Thanassis Tsiodras
> Real-time Embedded Software Engineer
> System, Software and Technology Department
> *
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> __Athanasios.Tsiodras at esa.int_ <mailto:Athanasios.Tsiodras at esa.int>|
> _www.esa.int_ <http://www.esa.int/>
> T +31 71 565 5332
>
>
>
> From:        "Jiri Gaisler" _<jiri at gaisler.se>_ <mailto:jiri at gaisler.se>
> To:        _Athanasios.Tsiodras at esa.int_
> <mailto:Athanasios.Tsiodras at esa.int>, "RTEMS List" _<users at rtems.org>_
> <mailto:users at rtems.org>
> Date:        08/02/2016 13:07
> Subject:        Re: Crash under sparc/rtems-4.11 when compiling with FPU
> ------------------------------------------------------------------------
>
>
>
>
>
> On 08/02/16 11:46, _Athanasios.Tsiodras at esa.int_
> <mailto:Athanasios.Tsiodras at esa.int>wrote:
> Hi Jerry.
>
> Thanks for the suggestion - indeed, If you look at my response to
> Jiri, you'll see that I verified that the -mhard-float is not
> necessary (objdump verified that FPU instructions are emitted by
> default, if you don't pass -msoft-float).
>
> I am now scripting my nightly build to do the patch explicitly, so I
> can follow the tip of 4.11 with native FPU support (our intended target).
>
> I didn't try the switch to v8 - since the removal of -msoft-float from
> leon3.cfg proved enough in my tests, and I am guessing the default
> leon3.cfg configuration was chosen to be -mcypress for a reason... At
> least I hope so :-)
>
>
> Just remember that if the compiler emits *any* FPU instruction in the
> kernel or non-FPU threads, you can get a crash. You should use objdump
> on the final binary to verify that you don't have spurious FPU
> instructions in the wrong place.
>
> Jiri.
>
>
>
> Thanks!*
>
> European Space Agency (via HE Space)*
> Thanassis Tsiodras
> Real-time Embedded Software Engineer
> System, Software and Technology Department*
>
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> __Athanasios.Tsiodras at esa.int_ <mailto:Athanasios.Tsiodras at esa.int>|
> _www.esa.int_ <http://www.esa.int/>
> T +31 71 565 5332
>
>
>
> From:        "Needell, Jerry" _<Jerry.Needell at unh.edu>_
> <mailto:Jerry.Needell at unh.edu>
> To:        _"Athanasios.Tsiodras at esa.int"_
> <mailto:Athanasios.Tsiodras at esa.int>_<Athanasios.Tsiodras at esa.int>_
> <mailto:Athanasios.Tsiodras at esa.int>
> Cc:        "Needell, Jerry" _<Jerry.Needell at unh.edu>_
> <mailto:Jerry.Needell at unh.edu>, "RTEMS List" _<users at rtems.org>_
> <mailto:users at rtems.org>
> Date:        08/02/2016 11:36
> Subject:        Re: Crash under sparc/rtems-4.11 when compiling with FPU
> ------------------------------------------------------------------------
>
>
>
> sorry for the typo - I meant -mcpu v8 …
> I have used this for bsps (RTEMS 4.9) with FPU without needing the
> -mhard-float specification
> For non FPU bsps I have used -msoft-float
> both with-mcpu v8
>
>
> On Feb 8, 2016, at 5:14 AM, Needell, Jerry <_Jerry.Needell at unh.edu_
> <mailto:Jerry.Needell at unh.edu>> wrote:
>
> I thought it was best to use -mv8 rather tahtn -mcypress for leon3
> bsps?  Does this make any difference in your case?
> On Feb 8, 2016, at 4:50 AM, _Athanasios.Tsiodras at esa.int_
> <mailto:Athanasios.Tsiodras at esa.int>wrote:
>
> I verified Sebastian's suggestion - by modifying the leon3.cfg file...
>
>    diff --git a/c/src/lib/libbsp/sparc/leon3/make/custom/leon3.cfg
> b/c/src/lib/libbsp/sparc/leon3/make/custom/leon3.cfg
>    index 58f2f07..30fc3a4 100644
>    --- a/c/src/lib/libbsp/sparc/leon3/make/custom/leon3.cfg
>    +++ b/c/src/lib/libbsp/sparc/leon3/make/custom/leon3.cfg
>    @@ -9,7 +9,8 @@ RTEMS_CPU_MODEL=leon3
>
>     #  This contains the compiler options necessary to select the CPU
> model
>     #  and (hopefully) optimize for it.
>    -CPU_CFLAGS = -mcpu=cypress -msoft-float
>    +CPU_CFLAGS = -mcpu=cypress -mhard-float
>
> ...the generated binary of hello.exe works fine - I went a step
> further and did a test calculation, too:
>
>    diff --git a/testsuites/samples/hello/init.c
> b/testsuites/samples/hello/init.c
>    index d8fe450..6ee33f6 100644
>    --- a/testsuites/samples/hello/init.c
>    +++ b/testsuites/samples/hello/init.c
>    @@ -27,8 +27,13 @@ rtems_task Init(
>       rtems_task_argument ignored
>     )
>     {
>    +  int i = 0;
>    +  float a=3.14159f, b=1.0f;
>    +
>       rtems_test_begin();
>    -  printf( "Hello World\n" );
>    +  for (i=0; i<10; i++)
>    +      b*=a;
>    +  printf( "Hello World, %f\n", b );
>       rtems_test_end();
>       exit( 0 );
>     }
>
> ...which worked fine:
>
>    (gdb) tar extended-remote ... ( to grmon)
>    (gdb) c
>    Continuing.
>
>    *** BEGIN OF TEST HELLO WORLD ***
>    Hello World, 1.000000
>    *** END OF TEST HELLO WORLD ***
>
> ...and I made sure that FPU instructions are inside:
>
>      for (i=0; i<10; i++)
>      28:   82 80 7f ff     addcc  %g1, -1, %g1
>      2c:   12 bf ff ff     bne  28 <Init+0x28>
>      30:   91 a2 09 29     fmuls  %f8, %f9, %f8
>          b*=a;
>      printf( "Hello World, %f\n", b );
>      34:   91 a0 19 28     fstod  %f8, %f8
>
> So, executive summary....  It seems that the default compilation
> settings of the Leon3 BSP forbid "real FPU" work.
> If one needs to work in native (non-emulated) FPU mode, then the
> leon3.cfg must be patched as I showed above.
>
> In the long run, as Sebastian indicated, a leon3fp (and a
> corresponding leon2fp, I imagine)
> should ideally be added as new BSP targets - and the FPU page
> (_https://devel.rtems.org/wiki/TBR/UserManual/Floating_Point_Support_)
> should probably
> be updated to indicate this.
>
> Thanks to everyone for their help,
> Thanassis.*
>
>
> European Space Agency (via HE Space)*
> Thanassis Tsiodras
> Real-time Embedded Software Engineer
> System, Software and Technology Department*
>
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> __Athanasios.Tsiodras at esa.int_ <mailto:Athanasios.Tsiodras at esa.int>|
> *_MailScanner has detected a possible fraud attempt from "x-msg:"
> claiming to be_*___www.esa.int_ <x-msg://11/www.esa.int>
> T +31 71 565 5332
>
>
>
> From:        "Sebastian Huber" <_sebastian.huber at embedded-brains.de_
> <mailto:sebastian.huber at embedded-brains.de>>
> To:        "RTEMS List" <_users at rtems.org_ <mailto:users at rtems.org>>
> Cc:        _software at gaisler.com_ <mailto:software at gaisler.com>
> Date:        07/02/2016 07:40
> Subject:        Re: Crash under sparc/rtems-4.11 when compiling with FPU
> Sent by:        "users" <_users-bounces at rtems.org_
> <mailto:users-bounces at rtems.org>>
> ------------------------------------------------------------------------
>
>
>
> Hello Athanasios,
>
> it was always a miracle to me how you are supposed to use the
> leon2/leon3 BSPs with a FPU. If you want to use the FPU, then the BSP
> must be built with the -mhard-float option, otherwise the FPU support
> is not enabled in the operating system support. In addition the
> application configuration must be compiled with exactly the same
> compiler flags as the BSP, otherwise it will generate a corrupt
> configuration.
>
> I think we need leon2fp and leon3fp BSPs, which use -mhard-float.
>
> -- 
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at _embedded-brains.de_
> <http://embedded-brains.de/>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> users mailing list_
> __users at rtems.org_ <mailto:users at rtems.org>_
> __http://lists.rtems.org/mailman/listinfo/users_
> This message and any attachments are intended for the use of the
> addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in
> whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and
> delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the
> sender.
>
> Please consider the environment before printing this email.
>
> _______________________________________________
> users mailing list_
> __users at rtems.org_ <mailto:users at rtems.org>_
> __http://lists.rtems.org/mailman/listinfo/users_
>
>
> This message and any attachments are intended for the use of the
> addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in
> whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and
> delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the
> sender.
>
> Please consider the environment before printing this email.
>
>
>
> _______________________________________________
> users mailing list_
> __users at rtems.org_ <mailto:users at rtems.org>_
> __http://lists.rtems.org/mailman/listinfo/users_
>
> This message and any attachments are intended for the use of the
> addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in
> whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and
> delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the
> sender.
>
> Please consider the environment before printing this email.
>
>
> This message and any attachments are intended for the use of the addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
>
> Please consider the environment before printing this email.

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


More information about the users mailing list