http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
Bug #: 53325
Summary: arm-rtems switch default target to EABI
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
I have to start by saying the RTEMS Project didn't manage the transition from
"ARM ELF" to "ARM EABI" as well as we have managed similar changes in the
past.
The crux of the issue is that the preferred RTEMS tool target is ALWAYS
CPU-rtems<version>. We have transitioned from a.out -> coff -> elf in the past
and always followed the same target renaming pattern.
1) provide alternative for old target CPU-rtemsOLD where
OLD is aout, coff, elf, etc.
- CPU-rtems stays tied to old
2) provide new target at CPU-rtemsNEW where new is
aout, coff, elf, eabi, etc
3) verify RTEMS builds and no obvious issues with NEW.
test what can be tested internally.
4) limited (1-2 week) open period for feedback and outside
testing
5) if no feedback/bugs, switch CPU-rtems to CPU-rtemsNEW
leaving CPU-rtemsOLD around as a backup
Using CPU-rtems* makes our build instructions and use very consistent across
the 15 or so architectures, RTEMS runs on.
This time, we missed something somewhere along the way and arm-rtems* got on
the obsolete list and arm-rtemseabi* became the preferred target name. That
breaks a very long standing and well documented pattern.
Myself and Sebastian Huber wrote and he tested these patches. From
http://www.rtems.org/pipermail/rtems-devel/2012-May/001001.html
o the target arm-rtemseabi4.11 should be renamed to arm-rtems4.11
providing the up to date ARM EABI version 5 tool chain,
o the target arm-rtemself4.11 provides the obsolete GNU EABI (also
known as ARM ELF) variant.
The patches for 4.6, 4.7, and the head are attached. We didn't remove the "ARM
ELF" rtems target at this point. That is left for removal when general gcc
clean up catches it.
GCC test suite results for arm-rtems4.11:
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00322.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00323.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00324.html
