Static section initializing

[Leon Pollak]

On Tuesday 25 November 2003 18:43, you wrote:
> > 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?
This was in mbx8xx BSP Makefile and I also found this in many other BSP 
sources Makefiles and tests (samples).
I am weak in this area, but I thought that this says to linker to take link 
commands from my file...


> > -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().
This array is set up, because when I call them (ctors) "manually" - everything 
works OK.:
       void (**p)(void) = __CTOR_LIST__ + 1;
        while (*p)
                (**p++)();


> 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.
No, the list is not empty, as I see it (above). The crtbegin.o object  
contains no assembler code for  _ini (only 4 entry commands).


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

I do not use objcopy at this stage.

My linkcmds contains the following:
-----------------------
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */

    KEEP (*crtbegin.o(.ctors))

    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */

    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
------------------------------




I also tried the following (found in another ppc board:
------------------------------

    /*  Initialization and finalization code.
     *
     *  Various files can provide initialization and finalization functions.
     *  The bodies of these functions are in .init and .fini sections. We
     *  accumulate the bodies here, and prepend function prologues from
     *  ecrti.o and function epilogues from ecrtn.o. ecrti.o must be linked
     *  first; ecrtn.o must be linked last. Because these are wildcards, it
     *  doesn't matter if the user does not actually link against ecrti.o and
     *  ecrtn.o; the linker won't look for a file to match a wildcard.  The
     *  wildcard also means that it doesn't matter which directory ecrti.o
     *  and ecrtn.o are in.
     */
    PROVIDE (_init = .);
    *ecrti.o(.init)
    *(.init)
    *ecrtn.o(.init)

    PROVIDE (_fini = .);
    *ecrti.o(.fini)
    *(.fini)
    *ecrtn.o(.init)

    /*
     *  C++ constructors and destructors for static objects.
     *  PowerPC EABI does not use crtstuff yet, so we build "old-style"
     *  constructor and destructor lists that begin with the list lenght
     *  end terminate with a NULL entry.
     */

    PROVIDE (__CTOR_LIST__ = .);
    /* LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) */
    *crtbegin.o(.ctors)
    *(.ctors)
    *crtend.o(.ctors)
    LONG(0)
    PROVIDE (__CTOR_END__ = .);
------------------------------


All the rest causes are above my comprehetion...:-))


> 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.
Ohhh!!!! You touched my most painful point - for me the application 
compilation and linking process looks so complicated and dependent on so many 
unclear internal to RTEMS factors, that I simply try not to touch it. I took 
the cdtest application and tried to modify it and to adapt to my needs. The 
problem is that when I run cdtest it has the same problem, which are simply 
not tested. 
My application seems to work now, except this initializing phase. I mean that 
application runs fine, but only for the first time after reset, because there 
is no static variables initializing.

-- 
Leon Pollak
leonp at plris dot com