This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: breaking ABI compatibility for ARM EABI implementation

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:

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

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 (

-- Jeff J.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]