_init magic for c++ (on sparc64)

[Sebastian Huber]

Hi,

sorry, my commit

2010-11-29	Sebastian Huber <sebastian.huber at embedded-brains.de>

	* libcsupport/src/newlibc_exit.c, score/src/threadhandler.c: Added
	support for .preinit_array, .init_array and .fini_array sections.

was broken.  It seems that HAVE_INITFINI_ARRAY is defined for nearly all
targets by Newlib, but only few linker command files respect this.  We probably
need a per target solution to support the .{preinit, init, fini}_array sections
mentioned in

	System V Application Binary Interface
		Chapter 5
			Initialization and Termination Functions

Apart from that, it seems the sparc64 tool chain is a bit unusual.  The crti.o
and crtn.o files are normally provided by the tool chain and contain the init
and fini sections.

On 11/30/2010 03:55 AM, Gedare Bloom wrote:
> Hi,
> 
> I'm trying to get C++ support working properly on the sparc64 target
> with usiii BSP. I'm having a little trouble figuring out how to make
> things work, and am hoping some general pointers might be floating out
> there for me to try.
> 
> In particular, previously I stitched in a worthless _init declaration
> in the BSPs' start.S file in order to get applications to compile, but
> this is not the "correct" way of getting the _init symbol.  I've read
> through http://www.rtems.com/wiki/index.php/Using_C_Plus_Plus which
> has been helpful, but I seem to be missing something in implementing
> the proper magic between bsp_specs, linkcmds, and other
> autotools-magic.
> 
> The usiii bsp_specs doesn't include crti.o/crtn.o like some other
> bsps, so perhaps that is an issue? I tried adding those to bsp_specs,
> but the libs aren't built/installed from the RPM, so I guess they
> probably aren't needed/generated by gcc...
> 
> Using the CVS head and sparc64-rtems4.11 tools from RPM, after I
> comment out the definitions of _init and _fini at the end of the
> libbsp/sparc64/shared/start.S file, I get the following error while
> linking hello world while building the usiii BSP:
> 
> Making all in hello
> gmake[5]: Entering directory
> `/home/gedare/work/simics/gems/gems-2.1.1-sparc64/simics_3_workspace/build-sparc64/b-usiiicvs/sparc64-rtems4.11/c/usiii/testsuites/samples/hello'
> sparc64-rtems4.11-gcc -B../../../../../usiii/lib/ -specs bsp_specs
> -qrtems -mcpu=ultrasparc3 -DUS3 -DSUN4U -gstabs -Wall
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
>  -mcpu=ultrasparc3 -DUS3 -DSUN4U   -o hello.exe init.o
> ../../../../../usiii/lib/no-barrier.rel
> ../../../../../usiii/lib/no-dpmem.rel
> ../../../../../usiii/lib/no-event.rel
> ../../../../../usiii/lib/no-msg.rel ../../../../../usiii/lib/no-mp.rel
> ../../../../../usiii/lib/no-part.rel
> ../../../../../usiii/lib/no-region.rel
> ../../../../../usiii/lib/no-signal.rel
> ../../../../../usiii/lib/no-timer.rel
> ../../../../../usiii/lib/no-rtmon.rel
> ../../../../../usiii/lib/no-ext.rel
> ../../../../../usiii/lib/librtemscpu.a(libscore_a-threadhandler.o): In
> function `_Thread_Handler':
> ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:148:
> undefined reference to `_init'
> /opt/rtems-4.11/lib/gcc/sparc64-rtems4.11/4.5.1/../../../../sparc64-rtems4.11/lib/libc.a(lib_a-init.o):
> In function `__libc_init_array':
> /builddir/build/BUILD/rtems-4.11-sparc64-rtems4.11-gcc-4.5.1/build/sparc64-rtems4.11/newlib/libc/misc/../../../../../gcc-4.5.1/newlib/libc/misc/init.c:40:
> undefined reference to `_init'
> collect2: ld returned 1 exit status
> gmake[5]: *** [hello.exe] Error 1
> 
> I'm just not quite sure how to proceed in trying to fix this, and
> thought someone out there might have some insight on this kind of
> problem.
> -Gedare
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.