[Bug 1765] New: Switch to ARM EABI version 5

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1765

           Summary: Switch to ARM EABI version 5
           Product: Tools
           Version: unspecified
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: GCC
        AssignedTo: ralf.corsepius at rtems.org
        ReportedBy: sebastian.huber at embedded-brains.de


Created an attachment (id=1135)
 --> (https://www.rtems.org/bugzilla/attachment.cgi?id=1135)
Patch against GCC 4.5.2.

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.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.