- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page