Implementation of ARM EABI library requirements?

[Jeff Johnston]

Mark Mitchell wrote:
> 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?
>
>   

I'm not personally sold on changing open-source to benefit proprietary 
vendors, but nevertheless, regarding changes to newlib, my first 
question is:  is full C99 spec conformance required?  Newlib isn't fully 
C99 compliant.

I have no objections to placing generic flags in the shared header files 
to hide macros/constants/types that require redefinition.  Regarding the 
redefinitions, if they don't overly clutter up the shared header files, 
then I would be ok with your proposal above to have a generic version.  
Otherwise, I would want them isolated to the ARM machine directory via 
the current function and header file override mechanisms already in 
place (e.g. defining a sys/stdio.h).

-- Jeff J.