changes for C++ constructors on psim

Fri May 7 04:28:45 UTC 2004

On Thu, 2004-05-06 at 23:34, Joel Sherrill wrote:
> Ralf Corsepius wrote:
> 
>  > Comments interspersed ...
>  >
>  > On Thu, 2004-05-06 at 00:08, JP Bonn wrote:
>  >

>  > Well, there had been similar proposals to other BSPs, before ... and ...
>  > they are causing me some headaches.
>  >
>  > IMO, such crt* handling should be added to gcc (i.e. to specs) instead
>  > of bsp_specs, because gcc's crt*-stuff is shared for all BSPs.
>  > Instead of adding crt*-stuff to BSPs' *startfile, *endfile, I'd prefer
>  > to see the BSP's *startfile, *endfile etc. use the original
>  > %(startfile), %(endfile), etc.
> 
> Agreed.  Long term, the more we can push out of bsp_specs and into
> gcc, the better off we are.  But 4.6 won't have this.
Well, we already have part of this.

cf. gcc/config/rtems.h in GCC's sources

It's some BSPs (in particular powerpc BSPs) trying to work around the
lack of generality in gcc/config/rtems.h.

I.e. from my point of view, adding crt* stuff to bsp_specs is the wrong
way. You are "adding local work arounds" to "global bugs".

>  > Unfortunately, I haven't found enough time to try implementing,
>  > therefore don't really know if it is possible,  and of cause don't have
>  > a patch proposal at hand.
>  >
>  >
>  >
>  >>diff -N -P -r -c rtems-4.6.1/c/src/tests/samples/cdtest/main.cc
>  >>rtems-4.6.1.mod/c/src/tests/samples/cdtest/main.cc
>  >>*** rtems-4.6.1/c/src/tests/samples/cdtest/main.cc	Thu Sep  4 
> 11:46:30 2003
>  >>--- rtems-4.6.1.mod/c/src/tests/samples/cdtest/main.cc	Tue May  4
>  >>14:14:06 2004
>  >>***************
>  >>*** 29,37 ****
>  >>  #include <stdio.h>
>  >>  #include <stdlib.h>
>  >>  #ifdef RTEMS_TEST_IO_STREAM
>  >>! #include <iostream.h>
>  >>  #endif
>  >>
>  >>  extern "C"
>  >>  {
>  >>  #include <tmacros.h>
>  >>--- 29,47 ----
>  >>  #include <stdio.h>
>  >>  #include <stdlib.h>
>  >>  #ifdef RTEMS_TEST_IO_STREAM
>  >>! #include <iostream>
> 
> This one is important to get rid of a warning. :)
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:

* <iostream> is not supported by older compilers (e.g. gcc < 3.0)
=> using <iostream> means giving up gcc < 3.0

* <iostream.h> is supported by all current gccs. 
gcc >= 3.0 warns about it.

* Switching between <iostream.h> and <iostream> with autoconf magic
probably introduces more problems than a single warning on a single file
does.

=> 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)
* Add autoconf magic to check for <iostream> and <iostream.h> and switch
between. This is the portable approach but is highly problematic in
detail. I'd rather not do this.
* Add autoconf magic to check for <iostream> and do not compile cdtest
if <iostream> is not present. Not much different from the previous
approach and similar problematic.
* 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)

>  >>  #endif
>  >>
>  >>+
>  >>+ void my_ctor (void) __attribute__ ((constructor));
>  >>+ void
>  >>+ my_ctor (void)
>  >>+ {
>  >>+ 	                printf ("hello before main()\n");
>  >>+ }
>  >
>  >
>  > As Chris already mentioned, C constructors are a GCC extension.
>  > Therefore this function should be guarded by __GNUC__ #defines.
>  >
>  > Also, you are adding "my_ctor" to a C++ file, i.e. you actually are
>  > attributing a C++ function as constructor. If you want to test C
>  > constructors, this function should be put into a separate *.c file, or
>  > be marked 'extern "C"'.
>  >
>  > Another issue is the '__attribute__(..)'.
>  > This is a GCC internal define. If you want the code to be portable you
>  > have to define it for non-GCC compilers.

>   I thought there were already global
> constructors in this test?
Cf. below.

>  >>+
>  >>+
>  >>  extern "C"
>  >>  {
>  >>  #include <tmacros.h>
>  >>***************
>  >>*** 134,141 ****
>  >>
>  >>
>  >>
>  >>! AClass foo( "GLOBAL" );
>  >>! BClass foobar( "GLOBAL" );
>  >>
>  >>  void
>  >>  cdtest(void)
>  >>--- 144,151 ----
>  >>
>  >>
>  >>
>  >>! AClass fooAClass( "GLOBAL fooAClass" );
>  >>! BClass fooBClass( "GLOBAL fooBClass" );
Here they are.

>  >>diff -N -P -r -c rtems-4.6.1/make/custom/psim.cfg
>  >>rtems-4.6.1.mod/make/custom/psim.cfg
>  >>*** rtems-4.6.1/make/custom/psim.cfg	Tue May 14 08:51:29 2002
>  >>--- rtems-4.6.1.mod/make/custom/psim.cfg	Tue May  4 14:25:24 2004
>  >>***************
>  >>*** 15,27 ****
>  >>  #  This contains the compiler options necessary to select the CPU model
>  >>  #  and (hopefully) optimize for it.
>  >>  #
>  >>! CPU_CFLAGS = -mcpu=603e -D_OLD_EXCEPTIONS -Dppc603e
>  >>  #-ffunction-sections
>  >>
>  >>  # optimize flag: typically -0, could use -O4 or -fast
>  >>  # -O4 is ok for RTEMS
>  >>  # NOTE: some level of -O may be actually required by inline assembler
>  >>  CFLAGS_OPTIMIZE_V=-O4 -fno-keep-inline-functions
>  >>
>  >>  define make-exe
>  >>  	$(LINK.c) $(AM_CFLAGS) $(AM_LDFLAGS) -o $(basename $@).exe \
>  >>--- 15,35 ----
>  >>  #  This contains the compiler options necessary to select the CPU model
>  >>  #  and (hopefully) optimize for it.
>  >>  #
>  >>! CPU_CFLAGS = -mcpu=603e -D_OLD_EXCEPTIONS -Dppc603e -D__USE_INIT_FINI__
>  >
>  > __USE_INIT_FINI__ is a gcc-internal define and is supposed to be
>  > implicitly supplied by the compiler and should not be used on the
>  > command-line.
>  >
>  > If your compiler doesn't implicitly specify it, this would indicate a
>  > bug in the compiler.
> 
> I have placed new 4.6 gcc/new tools on the ftp server but haven't
> completed a round of 4.7 tools with the same fix and was holding
> off announcing until then.  Try those.

FYI: The rtems-4.6-powerpc-rtems-gcc-3.2.3-*4 does define
__USE_INIT_FINI__, my local rtems-4.7-powerpc-rtems4.7-3.4.0-* rpm
doesn't, I haven't tried your rtems-4.7-powerpc-rtems4.7-3.3.3-* rpms,
yet.

I'd have to check your gcc-3.3.3-patches, probably a patch has been lost
in gcc-3.4.0.

Ralf