More EABI/C++ issues (was Re: EABI and C++)

[Till Straumann]

I wonder if we can address the __init() vs. __eabi() with some
'spec' magic by giving the __USE_INIT_FINI__ symbol a value:

__Thread_Handler:

#ifdef __USE_INIT_FINI__
extern void (*__USE_INIT_FINI__)(void);
int    alreadyDone = (0 == __USE_INIT_FINI__);
#endif

...

#ifdef __USE_INIT_FINI__
     if (!alreadyDone) {
        alreadyDone = 1;
        __USE_INIT_FINI__();
     }
#endif

That way, every architecture may define __USE_INIT_FINI__
to the proper initialization routine.
BUT, it can even do more: A proper spec file could even
switch or disable the behavior AT LINK TIME, i.e. for
each individual application.

Let's look at powerpc: The spec file could predefine

-D__USE_INIT_FINI__=__rtems_app_init

and the linker specs could then do
{!mno-eabi: --defsym __rtems_app_init=__eabi}
{mno-eabi:  --defsym __rtems_app_init=0}

Hence, an application linked with -mno-eabi will
have the __Thread_Handler's alreadyDone Varible magically
initialized to 1 and hence nothing happens.

An application built with -meabi {which is AFAIK the default}
correctly calls __eabi().

A real gcc expert should look at this issue - sorry, I have
already devoted too much time to this. I guess I'll locally
fix it here in the way described above until someone
comes up with a better idea.

-- Till