Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

C++ global constructors not being called

We are using version 1.0.0 build 393 of the Nios II IDE and bringing up an application under uClinux. The problem du jour is that it appears the constructors for globally defined C++ objects are not being invoked at startup.

From the GNU documentation and various documentation fragments gleaned from the web, it appears that, for ELF binaries, the constructors show up in a segment named .ctor and are preceded by a label __CTOR_LIST__, and they are supposed to be all called before main is invoked (possibly by the _init() function). Another fragment indicates that there should be a pair of .o files, crtbegin.o and crtend.o, which are sandwiched around the application and between crti.o and crtn.o, but they don't appear to exist anywhere. The .ctor (and .dtor for global destructors) do not show up in ELF object post-link, and the label __CTOR_LIST__ doesn't exist.

Has anyone else had this problem? If so, how did you fix it?

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Hi halfdone,

    > The .ctor (and .dtor for global destructors) do not show up in ELF object post-link

    Hmmm ... these are _normally_ wrapped in a KEEP and show up regardless. Better

    check your default linker script.

    Regards,

    --Scott
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Thanks, Scott, for the reminder about the linker script. It indeed rolled the .ctors and .dtors sections into .text but didn't provide a label by which to access them, so I've added that and put in a function to run through and call the constructor function pointers in sequence. We've done that on past projects where we provided the entire runtime support. I haven't found anywhere in the documentation that says we need to do that here, but there it is. So now I just need to figure out how to get rid of the 4 bytes of extraneous garbage libpthread.a has in a .ctors section (in pthread.o; pthread is a C library, isn't it??) which my function dutifully calls, sending it to Never Never Land.