breaking ABI compatibility for ARM EABI implementation

[Jeff Johnston]

Nathan Froyd wrote:
> We have started adding compile-time support to Newlib for ARM's C
> library ABI to our internal codebase.  When the work is done, we'd like
> to contribute the work back upstream; Mark Mitchell wrote a message
> several months ago inquring about the upstream suitability of adding the
> necessary preprocessor bits to the headers:
>
> http://sourceware.org/ml/newlib/2007/msg01150.html
>
> In addition to the necessary preprocessor bits, and contrary to Mark's
> original statement that backwards compatibility would not be affected,
> we've found that there is at least one change that would be
> ABI-breaking: fpos_t is required to be specified like so:
>
> typedef struct {
>   long long pos;
>   mbstate_t mbstate;
> } fpos_t;
>
> Obviously, we can't specify fpos_t like this only when compiling
> portable code for the ARM EABI, or even when compiling for ARM
> generally; it needs to be an unconditional change.  If we did do
> something like this, then fpos64_t as well as fpos_t would likely
> change, for consistency's sake.
>
> Would this sort of change be accepted upstream?  Is there any policy on
> breaking ABI compatibility in Newlib?  Given that Newlib is usually
> statically linked into applications, the impact of making this sort of
> change are lessened, but it's still something that needs to be
> considered.  One positive outcome of this, ARM EABI compliance aside, is
> that making this change makes linking with either Newlib or GLIBC
> slightly easier (GLIBC's fpos_t is either 12 bytes or 16 bytes,
> depending on what _FILE_OFFSET_BITS is at compile time) independent of
> compiling in the special ARM EABI mode.
>
> We can implement the remainder of the ARM EABI without making this
> change; however, stdio.h would be marked as not-compliant with the ARM
> EABI, which seems unfortunate given the wide use of this header in
> applications.  We'd prefer to provide a complete ARM EABI environment
> instead.
>
>   

There is no reason you need to change the shared stdio.h.  Any platform 
can define its own header files which override the shared system files.  
The platform can also override any shared C function with its own 
implementation.

Thus, arm-eabi can have its own copy of stdio.h.  It can have its own 
fgetpos and fsetpos implementation.  It can have its own types.h, 
etc...  without requiring changes in other platforms.

The mechanics are simple.  To override any C library function, you 
simply supply a .o file of the same name (assuming static linkage).  It 
will overwrite the shared version.  In the libc/machine/xxxx directory, 
simply have a  directory called "include" and these include files will 
overwrite the regular shared header files (e.g. stdio.h).  There is also 
the "machine" directory which is used for machine header files (e.g. 
machine/endian.h) and "sys" which is used for sys header files (e.g. 
sys/types.h).  The header files are installed so the end-user sees these 
header files and they are used during the build.

If you want to have arm separate from arm eabi, then in configuration 
simply define a different machine directory for one vs the other 
(configure.host).

-- Jeff J.
> Thanks,
> -Nathan
>