ARM GCC machine options for RTEMS 6

Joel Sherrill joel at rtems.org
Sun Jul 5 15:27:23 UTC 2020


On Sat, Jul 4, 2020, 10:20 PM Chris Johns <chrisj at rtems.org> wrote:

> On 4/7/20 5:43 pm, Sebastian Huber wrote:
> > On 04/07/2020 01:03, Chris Johns wrote:
> >> On 3/7/20 5:06 pm, Sebastian Huber wrote:
> >>> Hello,
> >>> someone from ARM changed the machine options used to build the RTEMS
> multilibs
> >>> some time ago (I think GCC 8):
> >> Was a reason given?
> > ARM thinks the new options are easier to use.
>
> Hmm.
>
> >>> arm-rtems6-gcc -print-multi-lib -march=armv4t
> >>> .;
> >>> thumb;@mthumb
> >>> armv5te+fp/hard;@march=armv5te+fp at mfloat-abi=hard
> >>> thumb/armv6-m;@mthumb at march=armv6-m
> >>> thumb/armv7-a;@mthumb at march=armv7-a
> >>> thumb/armv7-r;@mthumb at march=armv7-r
> >>> thumb/cortex-m3;@mthumb at mcpu=cortex-m3
> >>> thumb/cortex-m4+nofp;@mthumb at mcpu=cortex-m4+nofp
> >>> thumb/armv7-a+simd/hard;@mthumb at march=armv7-a+simd at mfloat-abi=hard
> >>> thumb/armv7-r+fp/hard;@mthumb at march=armv7-r+fp at mfloat-abi=hard
> >>> thumb/cortex-m4/hard;@mthumb at mcpu=cortex-m4 at mfloat-abi=hard
> >>> thumb/cortex-m7/hard;@mthumb at mcpu=cortex-m7 at mfloat-abi=hard
> >>> eb/thumb/armv7-r;@mbig-endian at mthumb@march=armv7-r
> >>> eb/thumb/armv7-r+fp/hard;@mbig-endian at mthumb@march
> =armv7-r+fp at mfloat-abi=hard
> >>>
> >>> It seems that our current machine options still map to the right
> multilib:
> >>>
> >>> arm-rtems6-gcc -print-multi-directory -march=armv7-a -mthumb -mfpu=neon
> >>> -mfloat-abi=hard -mtune=cortex-a9
> >>> thumb/armv7-a+simd/hard
> >>>
> >>> arm-rtems6-gcc -print-multi-directory -mthumb -mcpu=cortex-m4
> -mfpu=fpv4-sp-d16
> >>> -mfloat-abi=hard
> >>> thumb/cortex-m4/hard
> >>>
> >>> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb
> -mbig-endian
> >>> eb/thumb/armv7-r
> >>>
> >>> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb
> -mbig-endian
> >>> -mfpu=vfpv3-d16 -mfloat-abi=hard
> >>> eb/thumb/armv7-r+fp/hard
> >>>
> >>> Should we change the options to match the ones given in the multilib
> definition
> >>> or should we keep the current options? If we change the options, then
> we can no
> >>> longer build with GCC 7.
> >> Would we need to build gcc 7 for RTEMS 6?
> >
> > No, but for a git bisect it would be nice to use the RTEMS 5 compiler
> for a
> > while for the master branch.
>
> Sure.
>
> > Since the new build system will be a hard break, maybe we should keep the
> > options as is in the old build system and start with the new options in
> the new
> > build system.
>
> This seems reasonable.
>

And how will we know which change broke something?


> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200705/fa2a49e6/attachment.html>


More information about the devel mailing list