Crash under sparc/rtems-4.11 when compiling with FPU
Jiri Gaisler
jiri at gaisler.se
Mon Feb 8 18:56:34 UTC 2016
On 08/02/16 13:25, 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 | 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160208/8f2f1b57/attachment-0002.html>
More information about the users
mailing list