changes for C++ constructors on psim

[Joel Sherrill]

Ralf Corsepius wrote:
> On Fri, 2004-05-07 at 08:20, Chris Johns wrote:
> 
>>Ralf Corsepius wrote:
>>
>>>Sorry, no. We had been using <iostream.h> on purpose, because <iostream>
>>>is a feature having been added by newer C++ standards, not being
>>>supported by older C++ compilers.
>>>
>>
>>This is to bring the test in line with the current standard which seems 
>>like a good idea.
> 
> 
> No problem with me ;)
> 
> 
>>>* <iostream> is not supported by older compilers (e.g. gcc < 3.0)
>>>=> using <iostream> means giving up gcc < 3.0
> 
> 
>>>=> Trying to use <iostream> will make further steps inevitable.
>>>Possible steps:
>>>* Rely on <iostream> and let building fail otherwise (I.e. abandon gcc <
>>>3.0)
>>
>>Seems ok with me. Can you build RTEMS with older versions of GCC (<3.0) 
>>now ?
> 
> I don't know ;)

I attempted to produce a gcc 2.95.x for i960 as a terminal toolset
a while back and got frustrated and quit.  I am sure it is possible
but not worth the effort to me personally just to say that it works.
This is in the category of "would require paid attention". :)

So I say abandon gcc C++ < 3.0.

> I am pretty certain the C-parts build. I am quite sure C++ builds for
> most targets, but I would not bet if C++ works. 

Hard to say.  There is so much per-BSP tinkering to get right.

>>My understanding is you could not for other reasons such as movement of 
>>system header files.

This is just what makes the supporting of new RTEMS and newlib with
old gcc a pain.  You have to refight all the old C header battles and
reintegrate everything.  The balance of .h files between RTEMS, newlib
and gcc is a delicate dance.

> Well, this isn't the real problem with RTEMS and C++.
> 
> Off hand, IIRC, the only c++ system header the RTEMS source-tree uses is
> the <iostream> inclusion in cdtest, we are discussing here. cdtest is
> "just an application" and not part of the actual OS. So this doesn't
> have much impact on "The RTEMS OS" and the "RTEMS API"
> 
> The actual C++ problems are elsewhere:
> * Interfacing RTEMS memory management to libstdc++/g++ (The static
> constructors issues)
> * Interfacing RTEMS to libstdc++/g++ (libstdc++/config/*)
> * Frequent general changes to internal of libstdc++ in GCC (E.g.
> remember the atomic locks).
> * Interfacing GCC's c++ to its target low level backends (Most of the
> problematic parts we are discussing here, actually are implemented at
> the lowest level in gcc).
> 
> I.e. the actual problem with C++ and RTEMS is not C++ code but the C++
> implementation details in GCC itself and implicit assumptions BSPs make
> on compilers' behaviors.

Yes.  C++ has a lot of details that change and have to be dealt with
in hard/odd places.  The fact that a BSP's linker script can break
C++ makes it hard to keep working.

> ATM, it's static constructors again (Yes, we've had this issue before,
> IIRC, between gcc-2.95.x and gcc-3.0), it had been RTEMS thread support
> and architecture specific locks in libstdc++, and I would not be too
> much astounded if resolving the libstdc++/config/* warnings in gcc >=
> 3.4.0 might have one or more surprise lurking ;)

Yes.  main() moved from RTEMS space to application space and global ctor
execution had to move in the initialization sequence.

>>>* Stay with <iostream.h> and live with the warning. Confusing to users,
>>>the least problematic approach until somebody wants to use a compiler
>>>without it (i.e. until gcc abandons "backward" headers - AFAICT, even
>>>gcc-3.5 still has them, and I don't recall having read about a
>>>time-frame to finally abandon them)
>>
>>Not too concerned which way this one goes.
> 

Me either.  I am supporting a C++ application and it seems as though
it is hard to find two gcc versions on Linux which do the same thing.
We have tried various Linux versions in an attempt to be more or less
compiler version independent and it has been a bit painful to keep
things compiling everywhere.

> OK, I'll look into this.
> 
> Ralf
> 
>