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.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
2011-04-05 Sebastian Huber <sebastian.hu...@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
