This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Deprecating ARM FPA support
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, Martin Guy <martinwguy at gmail dot com>, Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "pedro at codesourcery dot com" <pedro at codesourcery dot com>, Nathan Sidwell <nathan at codesourcery dot com>, "ljrittle at acm dot org" <ljrittle at acm dot org>, "ralf dot corsepius at rtems dot org" <ralf dot corsepius at rtems dot org>, "thorpej at netbsd dot org" <thorpej at netbsd dot org>, "krister dot walfridsson at gmail dot com" <krister dot walfridsson at gmail dot com>
- Date: Mon, 24 May 2010 06:40:52 -0500
- Subject: Re: Deprecating ARM FPA support
- References: <AANLkTimkz9SCy1XXHOsduUsboMv-yi4DYFxkCljPdCqO@mail.gmail.com> <1274689403.17090.23.camel@e102346-lin.cambridge.arm.com> <Pine.LNX.4.64.1005241112020.14000@digraph.polyomino.org.uk>
On 05/24/2010 06:33 AM, Joseph S. Myers wrote:
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for the relevant maintainers, which in this case means target
maintainers together with OS maintainers (or target maintainers alone if
noone is maintaining the OS ports to ARM).
On Mon, 24 May 2010, Richard Earnshaw wrote:
OABI should be on the deprecated list too, as should all ports that
derive from the APCS or ATPCS rules. The point of this deprecation
process is to allow us to sort out a lot of historical kinks in the
compiler.
What ABI does WinCE use? I don't think it's EABI-based; it's not even
ELF. When you're dealing with an OS not built with GCC, GCC gets to
follow the ABI defined for that OS, just like the x86_64 Windows port has
to deal with ABI differences from the ELF psABI for x86_64, for example.
For OSes built with GCC (which I think is all the non-WinCE ARM targets)
there is more of a scope for transitioning to a new ABI and not supporting
old OS versions (and so removing arm-linux, arm-elf).
I recently noted that VxWorks is not yet using EABI - but is certainly
still supporting ARM. Now, if it transitions, I think it was established
some years ago that GCC does not generally try to support older VxWorks
versions.
Is the ARM RTEMS port going to move to EABI?
We are watching this discussion and see where it leads us.
RTEMS targets are normally one side-step from XXX-elf and
that was what lead us to use arm-elf. If it has issues that
make it not the preferred target for embedded ARM work,
then we will need to move. We have transitioned from COFF
to ELF in the past for similar reasons.
I think I triggered this discussion by asking why so many
tests failed on arm-rtems that had nothing to do with
anything RTEMS could break. If it takes moving to arm-eabi
to get a well supported target that passes tests, we will
move. We compile everything from source.
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
Are the ARM ports of FreeBSD or NetBSD moving to EABI? (I think we can
kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old
a.out-based NetBSD - and more generally any other a.out BSD ports.) Old
in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI
support.
Is there anyone maintaining arm*-*-ecos-elf?
I hope none of the above ports are using FPA.
--joel