changes for C++ constructors on psim
Joel Sherrill
joel.sherrill at OARcorp.com
Thu May 6 21:34:31 UTC 2004
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
More information about the users
mailing list