[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

changes for C++ constructors on psim



Ralf Corsepius wrote:

 > Comments interspersed ...
 >
 > On Thu, 2004-05-06 at 00:08, JP Bonn wrote:
 >
 >>This is against the 4.6.1 release.  I plan on making a formal patch but
 >>it'll be a little bit.  These changes make the cdtest program, including
 >>iostreams, work on psim. There are also changes to cdtest that are
 >>independent of the psim changes that allow it to compile if iostreams
 >>are used.
 >>
 >>I wanted someone who understand RTEMS to check that I was setting flags
 >>in the proper files. The linker script changes are the same as some of
 >>the other bsps.
 >>
 >>=======================================================================
 >>
 >>diff -N -P -r -c rtems-4.6.1/c/src/lib/libbsp/powerpc/psim/bsp_specs
 >>rtems-4.6.1.mod/c/src/lib/libbsp/powerpc/psim/bsp_specs
 >>*** rtems-4.6.1/c/src/lib/libbsp/powerpc/psim/bsp_specs	Fri Aug 22
 >>11:50:48 2003
 >>--- rtems-4.6.1.mod/c/src/lib/libbsp/powerpc/psim/bsp_specs	Tue May  4
 >>14:14:06 2004
 >>***************
 >>*** 10,21 ****
 >>  %{!qnolinkcmds: -T linkcmds%s}}}
 >>
 >>  *startfile:
 >>! %{!qrtems: %(old_startfile)} %{!nostdlib: %{qrtems:  ecrti%O%s \
 >>  %{!qrtems_debug: start.o%s} \
 >>  %{qrtems_debug: start_g.o%s}}}
 >>
 >>  *endfile:
 >>! %{!qrtems: %(old_endfile)} %{qrtems: ecrtn%O%s}
 >>
 >>  *link:
 >>  %{!qrtems: %(old_link)} %{qrtems: -Qy -dp -Bstatic -e _start -u 
__vectors}
 >>--- 10,21 ----
 >>  %{!qnolinkcmds: -T linkcmds%s}}}
 >>
 >>  *startfile:
 >>! %{!qrtems: %(old_startfile)} %{!nostdlib: %{qrtems:  ecrti%O%s
 >>crtbegin%O%s \
 >>  %{!qrtems_debug: start.o%s} \
 >>  %{qrtems_debug: start_g.o%s}}}
 >>
 >>  *endfile:
 >>! %{!qrtems: %(old_endfile)} %{qrtems: crtend%O%s ecrtn%O%s}
 >>
 >>  *link:
 >>  %{!qrtems: %(old_link)} %{qrtems: -Qy -dp -Bstatic -e _start -u 
__vectors}

I think this is similar to what I had to do locally but have not
committed.  I had to add crtbegin and crtend.

I also noticed that the linkcmds did not have a .jcr section.  Not
that this is relevant to this problem.

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

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

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

Why was this even needed?  I thought there were already global
constructors in this test?

 >>+
 >>+
 >>  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" );
 >>
 >>  void
 >>  cdtest(void)
 >>***************
 >>*** 144,150 ****
 >>      BClass bleak;
 >>
 >>  #ifdef RTEMS_TEST_IO_STREAM
 >>!     cout << "Testing a C++ I/O stream" << endl;
 >>  #else
 >>      printf("IO Stream not tested\n");
 >>  #endif
 >>--- 154,160 ----
 >>      BClass bleak;
 >>
 >>  #ifdef RTEMS_TEST_IO_STREAM
 >>!     std::cout << "Testing a C++ I/O stream" << std::endl;
 >>  #else
 >>      printf("IO Stream not tested\n");
 >>  #endif
 >>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.

I also had to configure more semaphores.  I think the C++ library
and STL are using them but I have not determined what they are
allocated for and how many you really would need.  I don't know
if there is a fixed set or if they are allocated as more objects
are used.  If someone knows or could ask that on a gcc list and
track the answer, it would be good.  We really do need to know
how to configure systems properly.

--joel