(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? 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. -- Joseph S. Myers jos...@codesourcery.com
