change log for rtems (2011-08-29)

[Ralf Corsepius]

On 08/30/2011 02:22 PM, Joel Sherrill wrote:
> On 08/30/2011 04:21 AM, Ralf Corsepius wrote:
>> On 08/30/2011 12:12 AM, rtems-vc at rtems.org wrote:
>>> *joel*
>>>
>>> 2011-08-29 Joel Sherrill<joel.sherrilL at OARcorp.com>
>>
>>> diff -u rtems/cpukit/score/src/threadhandler.c:1.35
>>> rtems/cpukit/score/src/threadhandler.c:1.36
>>> --- rtems/cpukit/score/src/threadhandler.c:1.35 Mon Aug 15 03:23:49 2011
>>> +++ rtems/cpukit/score/src/threadhandler.c Mon Aug 29 16:30:32 2011
>>> +/*
>>> + * Conditional magic to determine what style of C++ constructor
>>> + * initialization this target and compiler version uses.
>>> + */
>>> #if defined(__AVR__)
>>> #undef __USE_INIT_FINI__
>>> #endif
>> WTH is this? It's definitely wrong.
>
> Obviously my change added a comment. The code itself was
> unchanged and those lines have been there for 3 years. (20 Nov 2008).
>
> My recollection is that the C++ ctor/dtor handling is based on that in
> the only other avr-gcc toolset and how avr-libc does it.

So, how does the avr initialize ctors/dtors?

> This was not
> invented for RTEMS but copied.
__USE_INIT_FINI__ is an RTEMS proprietary thing in GCC.

i.e. this #undef indicates a bug in the avr-toolchain and/or the 
avr-port. We explicitly provide __USE_INIT_FINI__ for avr-rtems.

@Sebastian: Similar considerations apply to the
ARM_EABI __libc_init_array. In my understanding, CodeSourcery 
implemented their proprietary way to handle ctors/dtors into newlib, 
which now clashes with RTEMS __USE_INIT_FINI__ in GCC and RTEMS.