Static section initializing

Ralf Corsepius corsepiu at faw.uni-ulm.de
Tue Nov 25 16:43:35 UTC 2003


On Tue, 2003-11-25 at 17:17, Leon Pollak wrote:
> On Tuesday 25 November 2003 18:06, Ralf Corsepius wrote:
> > On Tue, 2003-11-25 at 16:46, Leon Pollak wrote:
> > > On Tuesday 25 November 2003 18:03, gregory.menke at gsfc.nasa.gov wrote:
> > > > IIRC, _init is empty because you don't have quite the right set of
> > > > system libraries in your link script.  I think you need to include the
> > > > crtbegin, crtend- which gcc generates.  Look at the motorola_shared
> > > > bsp's link script- last time I used C++ in RTEMS it handled the
> > > > constructors properly.
> > >
> > > Gregory, thanks for the hint, but I have something wrong:
> > >
> > > 	In my gcc installation (which was downloaded from the RTEMS site
> > > powerpc-rtems-gcc (GCC) 3.2.2 (OAR Corporation
> > > gcc-3.2.2-20030326/newlib-1.11.0-20030326-2)
> > >
> > >  there are files like crtbegin.o, but they do not contain any _init/_fini
> > > symbols. Contrary, there are ecrti.o files which do contain _init/_fini,
> > > but these are empty (I made objdump -s).
> > >
> > > 	Do you have any idea where the working _init resides?
> >
> > They should have been produced by the compiler.
> >
> > Are you sure to be using 'g++' to *link*? You must use 'g++' instead of
> > 'gcc' or 'ld' to *link* c++ applications.
> > What you describe, matches the symptoms of using gcc to link.
> >
> > Ralf
> 
> OK, if such a high qualified person as Ralf does not know the answer 
> immediately,
I would not consider me highly qualified wrt. to the powerpc :-)

>  I am calm - the problem is not the result of my stupidity...:-))
> 
> No, Ralf, the linker is called as following:
> powerpc-rtems-g++ -o DTC_DEBUG 
> -B/opt/rtems/rtems-bin/powerpc-rtems/FDR_GEN/lib/ -specs bsp_specs -mcpu=860 
> -Dmpc860 -qrtems -qrtems_debug -Wno-unused -ggdb -g -Wall -fasm 
> -qnolinkcmds 
^^^^^^^^^^^^^^ this seems odd to me. Where does it come from?

> -T linkcmds -Xlinker -Map -Xlinker map.map __AND_MY_OBJ_FILES_LIST__
> 
> But why do you think that this is linker problem, when I do not see 
> _init/_fini code in gcc files?
Normally [1], g++ invokes collect2 (the c++ linker) to set up an array
of ctors/dtors in a special linker section which, the start up "works
off" before entering main().

Now, you are saying "init/fini" is empty, could indicate that something
might go wrong in g++/collect2/ld's interaction, over all causing the
static constructor/destructor arrays/list to get lost.

Possible causes could be not using 'g++' to link, a bug in the linker
script (dropping the ctors/dtors section(s)), a bug in the
powerpc-frontend in gcc (e.g. not using the correct ctors/dtors
implementation) or (in case you are using it) objcopy to strip off the
relevant sections from your binary.

Seeing the -qnolinkcmds above makes me wonder, because it normally isn't
applied to linking applications. I would not be surprised if it is the
culprit.

Ralf

[1] This is highly target dependent and differs significantly for
different targets.
 




More information about the users mailing list