Implementation of ARM EABI library requirements?

[Mark Mitchell]

Schwarz, Konrad wrote:
>>> 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.)
> 
> Just out of interest: how much practical interest is there in these
> extensions?

That's hard to say.  We're certainly asked often about combining
RealView (ARM's proprietary tools) code with GCC code on ARM processors,
but people don't usually ask explicitly about the library issue.

As I hinted in the previous message, I'm not actually testing the waters
with Newlib on behalf of ARM, or even a user of ARM CPUs; the interest
is from another party on other CPUs who is looking for a way to write
library-independent code.

> Using link-time constants entails that it is no longer possible to
> initialize constant data with non-trivial expressions containing such
> constants -- trivial being the usual constant + base supported by
> relocating linkers, right?

I'm not sure about exactly which relocations might be permitted, but the
basic point is correct: if you define the macro that requests a portable
run-time library, you pay a cost because constants are not known until
link-time, and therefore cannot be optimized as well by the compiler.
Note that the macro gives you a choice: an ordinary Newlib user would
see no difference in performance, but one that wanted to be able to link
with another library would see somewhat inferior code in return for
portability.

> The entire problem goes away if the supplier of binary components
> compiles his code with his compiler, but using the target tool-chain's
> header files (with suitably protected tool-chain-specific extensions,
> possibly extended by the local compiler's extensions), right?

Yes -- but that still doesn't solve the problem of distributing a single
application library (e.g., a video codec) that can be linked with any of
several C libraries.  The motivation behind ARM's specification is to
permit users to build something (a codec) and then link it with GLIBC,
Newlib, RealView's C library, the VxWorks C library, etc.  The same
benefits would apply on other architectures.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713