RE: Implementation of ARM EABI library requirements?

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

Thanks very much for your answer.

> >>> 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.)

I originally thought that with "link-time constant" you meant an
expression of the form (int) &__aeabi_LC_COLLATE,
where __aeabi_LC_COLLATE has been declared earlier as extern char const
__aeabi_LC_COLLATE[]; or similar.

I scanned over the ARM document and now think the idea is to declere it
as extern int const LC_COLLATE;.

Both solutions are non-conforming, in that it is no longer possible to
define, e.g., int const var = LC_COLLATE | 42,
however, the first idea of using a symbol at least allows int const var
= LC_COLLATE + 42; (at least when using ELF as the object format).  That
is why I spoke of "relocations" in my earlier mail.

In fact, with the extern int const solution, you can't even define int
const var = LC_COLLATE; and you have to pay a run-time cost for each use
of LC_COLLATE; the pointer solution has neither of these disadvantages.

Regards,

Konrad Schwarz