| Message ID | 4D9C84C8.8080900@embedded-brains.de |
|---|---|
| State | New |
| Headers | show |
On 04/06/2011 05:20 PM, Sebastian Huber wrote: > there were several requests for ARM Cortex-M support on RTEMS recently. The > first step towards this is a suitable ARM tool chain. I want to use this event > to clean up the multilibs and switch to the EABI version 5. The benefit of > EABI version 5 is that this brings RTEMS more in line with the primary GCC > platform arm-linux-gnueabi. These patches are not OK with me, because these are widely incompatible to what has been used in RTEMS up today and because these patches diverge with what we've discussed in RTEMS before. I'd propose you to implement an arm-*rtemseabi target which would allow a gradualy transition to eabi. Ralf
On 06/04/11 18:24, Ralf Corsepius wrote: > On 04/06/2011 05:20 PM, Sebastian Huber wrote: > >> there were several requests for ARM Cortex-M support on RTEMS >> recently. The >> first step towards this is a suitable ARM tool chain. I want to use >> this event >> to clean up the multilibs and switch to the EABI version 5. The >> benefit of >> EABI version 5 is that this brings RTEMS more in line with the >> primary GCC >> platform arm-linux-gnueabi. > > These patches are not OK with me, because these are widely > incompatible to what has been used in RTEMS up today Can you please list these incompatibilities. The RTEMS test suite shows no problems with this tool chain. The GCC test suite looks also good. > and because these patches diverge with what we've discussed in RTEMS > before. This is exactly the patch that is in the corresponding RTEMS PR 1765 (https://www.rtems.org/bugzilla/show_bug.cgi?id=1765). I only did what you suggested: send this patch to the GCC list for review. > > I'd propose you to implement an arm-*rtemseabi target which would > allow a gradualy transition to eabi. I don't share this opinion. If a RTEMS ARM user complains about the EABI tool chain, we can fix the problem or provide a legacy tool chain. -- 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@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
On 04/06/2011 07:20 PM, Sebastian Huber wrote: > On 06/04/11 18:24, Ralf Corsepius wrote: >> On 04/06/2011 05:20 PM, Sebastian Huber wrote: >> >>> there were several requests for ARM Cortex-M support on RTEMS >>> recently. The >>> first step towards this is a suitable ARM tool chain. I want to use >>> this event >>> to clean up the multilibs and switch to the EABI version 5. The >>> benefit of >>> EABI version 5 is that this brings RTEMS more in line with the >>> primary GCC >>> platform arm-linux-gnueabi. >> >> These patches are not OK with me, because these are widely >> incompatible to what has been used in RTEMS up today > > Can you please list these incompatibilities. The RTEMS test suite shows > no problems with this tool chain. The GCC test suite looks also good. [...] It is not really helpful to claim something without an explanation. The missing tool chain for the ARM Cortex architecture blocks RTEMS from further development on a very important embedded systems platform. A lot of competing real time operating systems provide ARM Cortex support for a long time. Lets look at the GCC test suite results: RTEMS 4.11, GCC 4.6.0 (EABI) === gcc Summary === # of expected passes 72429 # of unexpected failures 200 # of unexpected successes 7 # of expected failures 183 # of unresolved testcases 138 # of unsupported tests 1103 === g++ Summary === # of expected passes 25494 # of unexpected failures 11 # of unexpected successes 1 # of expected failures 160 # of unsupported tests 427 RTEMS 4.11, GCC 4.6.0 (old ABI) === gcc Summary === # of expected passes 43613 # of unexpected failures 15916 # of unexpected successes 8 # of expected failures 181 # of unresolved testcases 11127 # of unsupported tests 1124 === g++ Summary === # of expected passes 20709 # of unexpected failures 2590 # of expected failures 157 # of unresolved testcases 291 # of unsupported tests 430 RTEMS 4.10, GCC 4.4.5 (old ABI) === gcc Summary === # of expected passes 34293 # of unexpected failures 11273 # of expected failures 237 # of unresolved testcases 7878 # of unsupported tests 683 === g++ Summary === # of expected passes 15707 # of unexpected failures 1726 # of expected failures 155 # of unresolved testcases 26 # of unsupported tests 194 RTEMS 4.9, GCC 4.3.2 (old ABI) === gcc Summary === # of expected passes 47164 # of unexpected failures 2070 # of expected failures 97 # of unresolved testcases 92 # of untested testcases 35 # of unsupported tests 792 === g++ Summary === # of expected passes 17019 # of unexpected failures 52 # of unexpected successes 2 # of expected failures 82 # of unresolved testcases 49 # of unsupported tests 164 The EABI tool chain has by far the best test suite results. The RTEMS test suite was run with the edb7312 BSP and shows good results. It works also on real hardware with the lpc24xx and lpc32xx BSPs. All ARM BSPs compile and link all tests with the EABI tool chain. We use the VFP floating point format in all ARM BSPs since 2010-04-30. All ARM BSPs support the init and fini array sections since 2010-12-03. The C++ exceptions change from SJLJ to a table based implementation is an implementation detail. The required ARM/Thumb interwork is an enhancement. I don't claim that the switch to the EABI tool chain will be without problems, but we have to use it to figure this out. The multilib selection may need further changes. I am concerned about the enabled exceptions in some libgcc functions.
On 04/13/2011 03:38 AM, Sebastian Huber wrote: > On 04/06/2011 07:20 PM, Sebastian Huber wrote: >> On 06/04/11 18:24, Ralf Corsepius wrote: >>> On 04/06/2011 05:20 PM, Sebastian Huber wrote: >>> >>>> there were several requests for ARM Cortex-M support on RTEMS >>>> recently. The >>>> first step towards this is a suitable ARM tool chain. I want to use >>>> this event >>>> to clean up the multilibs and switch to the EABI version 5. The >>>> benefit of >>>> EABI version 5 is that this brings RTEMS more in line with the >>>> primary GCC >>>> platform arm-linux-gnueabi. >>> These patches are not OK with me, because these are widely >>> incompatible to what has been used in RTEMS up today >> Can you please list these incompatibilities. The RTEMS test suite shows >> no problems with this tool chain. The GCC test suite looks also good. > [...] > > It is not really helpful to claim something without an explanation. The > missing tool chain for the ARM Cortex architecture blocks RTEMS from further > development on a very important embedded systems platform. A lot of competing > real time operating systems provide ARM Cortex support for a long time. > > Lets look at the GCC test suite results: > Wow! The improvement is fantastic. These would impact only new release branches of RTEMS and we are months away from a new release branch. If something breaks, now if the time to find it out. > RTEMS 4.11, GCC 4.6.0 (EABI) > > === gcc Summary === > > # of expected passes 72429 > # of unexpected failures 200 > # of unexpected successes 7 > # of expected failures 183 > # of unresolved testcases 138 > # of unsupported tests 1103 > > === g++ Summary === > > # of expected passes 25494 > # of unexpected failures 11 > # of unexpected successes 1 > # of expected failures 160 > # of unsupported tests 427 > > RTEMS 4.11, GCC 4.6.0 (old ABI) > > === gcc Summary === > > # of expected passes 43613 > # of unexpected failures 15916 > # of unexpected successes 8 > # of expected failures 181 > # of unresolved testcases 11127 > # of unsupported tests 1124 > > === g++ Summary === > > # of expected passes 20709 > # of unexpected failures 2590 > # of expected failures 157 > # of unresolved testcases 291 > # of unsupported tests 430 > > RTEMS 4.10, GCC 4.4.5 (old ABI) > > === gcc Summary === > > # of expected passes 34293 > # of unexpected failures 11273 > # of expected failures 237 > # of unresolved testcases 7878 > # of unsupported tests 683 > > === g++ Summary === > > # of expected passes 15707 > # of unexpected failures 1726 > # of expected failures 155 > # of unresolved testcases 26 > # of unsupported tests 194 > > RTEMS 4.9, GCC 4.3.2 (old ABI) > > === gcc Summary === > > # of expected passes 47164 > # of unexpected failures 2070 > # of expected failures 97 > # of unresolved testcases 92 > # of untested testcases 35 > # of unsupported tests 792 > > === g++ Summary === > > # of expected passes 17019 > # of unexpected failures 52 > # of unexpected successes 2 > # of expected failures 82 > # of unresolved testcases 49 > # of unsupported tests 164 > > The EABI tool chain has by far the best test suite results. > > The RTEMS test suite was run with the edb7312 BSP and shows good results. It > works also on real hardware with the lpc24xx and lpc32xx BSPs. > > All ARM BSPs compile and link all tests with the EABI tool chain. > > We use the VFP floating point format in all ARM BSPs since 2010-04-30. > > All ARM BSPs support the init and fini array sections since 2010-12-03. > > The C++ exceptions change from SJLJ to a table based implementation is an > implementation detail. > > The required ARM/Thumb interwork is an enhancement. > > I don't claim that the switch to the EABI tool chain will be without problems, > but we have to use it to figure this out. The multilib selection may need > further changes. I am concerned about the enabled exceptions in some libgcc > functions. >
2011-04-05 Sebastian Huber <sebastian.huber@embedded-brains.de> * config.gcc (arm*-*-rtems*), config/arm/rtems-elf.h: Switch to ARM EABI version 5. * config/arm/t-rtems: Provide multilibs for ARMv4, ARMv4T, ARMv6M, ARMv7, and ARMv7M. diff --git a/gcc/config.gcc b/gcc/config.gcc index 58f6787..421279d 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -895,8 +895,14 @@ arm*-*-eabi* | arm*-*-symbianelf* ) tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" ;; arm*-*-rtems*) - tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h" - tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems" + need_64bit_hwint=yes + default_use_cxa_atexit=yes + tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h" + tm_file="${tm_file} ../../libgcc/config/arm/bpabi-lib.h" + tm_file="${tm_file} rtems.h arm/rtems-elf.h newlib-stdint.h" + tm_file="${tm_file} arm/aout.h arm/arm.h" + tmake_file="arm/t-arm arm/t-arm-elf" + tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems" tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" ;; arm*-*-elf) diff --git a/gcc/config/arm/rtems-elf.h b/gcc/config/arm/rtems-elf.h index dade74b..ad7e5b8 100644 --- a/gcc/config/arm/rtems-elf.h +++ b/gcc/config/arm/rtems-elf.h @@ -23,23 +23,10 @@ #define HAS_INIT_SECTION +#undef TARGET_OS_CPP_BUILTINS #define TARGET_OS_CPP_BUILTINS() \ do { \ builtin_define ("__rtems__"); \ - builtin_define ("__USE_INIT_FINI__"); \ builtin_assert ("system=rtems"); \ + TARGET_BPABI_CPP_BUILTINS(); \ } while (0) - -/* - * The default in gcc now is soft-float, but gcc misses it to - * pass it to the assembler. - */ -#undef SUBTARGET_EXTRA_ASM_SPEC -#define SUBTARGET_EXTRA_ASM_SPEC "\ - %{!mhard-float: %{!msoft-float:-mfpu=softfpa}}" - -/* - * The default includes --start-group and --end-group which conflicts - * with how this used to be defined. - */ -#undef LINK_GCC_C_SEQUENCE_SPEC diff --git a/gcc/config/arm/t-rtems b/gcc/config/arm/t-rtems index 52d14ba..9c68dc0 100644 --- a/gcc/config/arm/t-rtems +++ b/gcc/config/arm/t-rtems @@ -1,10 +1,6 @@ # Custom rtems multilibs -MULTILIB_OPTIONS = marm/mthumb -MULTILIB_DIRNAMES = arm thumb -MULTILIB_EXCEPTIONS = -MULTILIB_MATCHES = marm=mno-thumb - -MULTILIB_OPTIONS += msoft-float/mhard-float -MULTILIB_DIRNAMES += soft fpu -MULTILIB_EXCEPTIONS += *mthumb/*mhard-float* +MULTILIB_OPTIONS = mthumb march=armv6-m/march=armv7/march=armv7-m +MULTILIB_DIRNAMES = thumb armv6-m armv7 armv7-m +MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m +MULTILIB_MATCHES = marm=mno-thumb
Hello, there were several requests for ARM Cortex-M support on RTEMS recently. The first step towards this is a suitable ARM tool chain. I want to use this event to clean up the multilibs and switch to the EABI version 5. The benefit of EABI version 5 is that this brings RTEMS more in line with the primary GCC platform arm-linux-gnueabi. For standards related to this please have a look at the following documents. Base Platform ABI for the ARM Architecture (BPABI): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0037b/IHI0037B_bpabi.pdf ARM Architecture Procedure Call Standard (AAPCS): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf ELF for the ARM Architecture: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf The EABI makes the VFP floating point format mandatory and enables us to use hardware floating point support in the future. RTEMS has currently no support for hardware floating point units (the context switch part is missing). The Thumb interwork support is mandatory with this ABI. The exception handling implementation changes from SJLJ to a table-based system, which is not based on DWARF unwinding tables as they are too bulky for use on small embedded systems. I propose to change the ARM multilibs as follows: 1. Default: armv4, ARM 2. thumb: armv4t, Thumb 3. armv6-m: armv6-m, subset of Thumb 2 4. armv7: armv7, Thumb 2 5. armv7-m: armv7-m, Thumb 2, hardware integer division (SDIV/UDIV) Multilib 1. and 2. support the standard ARM7TDMI and ARM926EJ-S targets. Multilib 3. supports the Cortex-M0 and Cortex-M1 cores. Multilib 5. supports the Cortex-M3 and Cortex-M4 cores, which have a special hardware integer division instruction (this is not present in the A and R profiles). Multilib 4. supports Cortex-A and Cortex-R variants. Does this make sense? Please have a look at the attached patch. What bothers me a bit, is that some functions of libgcc are compiled unnecessarily with the -fexceptions flag. This pulls in the unwind mechanic for simple things like int64_t f(int64_t a, int64_t b) { return a / b; } Is is possible to make parts of libgcc/Makefile.am target specific? Have a nice day! PS: I am not subscribed to the gcc-patches list, so please CC me.