The ABI for the ARM Architecture specifies requirements for libraries
that permit modules to be linked with any compliant run-time library.
For example, a distributor could build some code with ARM's proprietary
compiler (using headers from that compiler), but we could then link it
with Newlib. The technical specification is available here:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0039a/IHI0039A_clibabi.pdf
The tricky bit (assuming that the compiler ABIs are already lined up) is
that the C libraries may use different values for constants (e.g.,
LC_COLLATE) and different implementations for macros (e.g., stdin and
<ctype.h>). These issues are resolved via indirection: LC_COLLATE
becomes a link-time constant, rather than a header-file constant, for
example. (That's not technically ISO C conformant, but most
applications don't care.)
The changes are conditional on preprocessor symbols, so it's possible to
implement the ABI specification without affecting backwards
compatibility, either at the source or binary level.
Despite the fact that the names used in the specification all begin with
"__aeabi", most of the specification is not architecture-specific. If
we were to implement this, I would suggest that we implement it (as an
option) for all architectures.
In principle, is there any reason that the Newlib maintainers would be
opposed to patches to do this?