[RTEMS Project] #1765: RTEMS Toolset Patch for ARM EABI version 5

[RTEMS trac]

#1765: RTEMS Toolset Patch for ARM EABI version 5
-----------------------------+-----------------------------
 Reporter:  sebastian.huber  |       Owner:  ralf.corsepius
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:  4.11
Component:  GCC              |     Version:
 Severity:  normal           |  Resolution:  fixed
 Keywords:                   |
-----------------------------+-----------------------------
Changes (by gedare):

 * version:  unspecified =>
 * type:  defect => enhancement
 * milestone:   => 4.11


Old description:

> 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 us 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 architecture 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 unwind tables
> (DWARF 2).
>
> 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.
>
> The ABI change will break the BSPs.  We have to adjust the linker command
> files
> to support the following sections:
>
>   .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
>
>    __exidx_start = .;
>   .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
>    __exidx_end = .;
>
>   .preinit_array     :
>   {
>     PROVIDE_HIDDEN (__preinit_array_start = .);
>     KEEP (*(.preinit_array))
>     PROVIDE_HIDDEN (__preinit_array_end = .);
>   }
>
>   .init_array     :
>   {
>      PROVIDE_HIDDEN (__init_array_start = .);
>      KEEP (*(SORT(.init_array.*)))
>      KEEP (*(.init_array))
>      PROVIDE_HIDDEN (__init_array_end = .);
>   }
>
>   .fini_array     :
>   {
>     PROVIDE_HIDDEN (__fini_array_start = .);
>     KEEP (*(.fini_array))
>     KEEP (*(SORT(.fini_array.*)))
>     PROVIDE_HIDDEN (__fini_array_end = .);
>   }
>
> We have to figure out how this affects the .init and .fini sections and
> there
> usage.  There is also a disadvantage with the new .init_arry and
> .fini_array
> sections.  These sections are in principle writeable to allow a loader of
> a
> shared library to fix up the pointers.  Since we do not support shared
> libraries we do not need this actually.
>
> The linker command files of all ARM BSPs were modified to support these
> sections.

New description:

 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 us 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 architecture 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 unwind tables
 (DWARF 2).

 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.

 The ABI change will break the BSPs.  We have to adjust the linker command
 files
 to support the following sections:

   .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) }

    __exidx_start = .;
   .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
    __exidx_end = .;

   .preinit_array     :
   {
     PROVIDE_HIDDEN (__preinit_array_start = .);
     KEEP (*(.preinit_array))
     PROVIDE_HIDDEN (__preinit_array_end = .);
   }

   .init_array     :
   {
      PROVIDE_HIDDEN (__init_array_start = .);
      KEEP (*(SORT(.init_array.*)))
      KEEP (*(.init_array))
      PROVIDE_HIDDEN (__init_array_end = .);
   }

   .fini_array     :
   {
     PROVIDE_HIDDEN (__fini_array_start = .);
     KEEP (*(.fini_array))
     KEEP (*(SORT(.fini_array.*)))
     PROVIDE_HIDDEN (__fini_array_end = .);
   }

 We have to figure out how this affects the .init and .fini sections and
 there
 usage.  There is also a disadvantage with the new .init_arry and
 .fini_array
 sections.  These sections are in principle writeable to allow a loader of
 a
 shared library to fix up the pointers.  Since we do not support shared
 libraries we do not need this actually.

 The linker command files of all ARM BSPs were modified to support these
 sections.

--

--
Ticket URL: <http://devel.rtems.org/ticket/1765#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project