Why does GCC put calls to constructors of global instances into different sections (depending on the target)?

Question

I have some simple declarations of a global instances with non-empty constructors. These constructors are called during startup automatically. I am cross-compiling C++ on Linux to different microcontroller targets.

---

As for

• arm-none-eabi-gcc-4.8.4
• rx-elf-gcc-4.8-GNURX_v14.03 (GCC 4.8.3)

calls to constructors are put into the .init_array section. The map file looks like this:

.init_array 0x00007cb8 0x4 libmotor.o

.init_array 0x00007cbc 0x4 libaudio.o

---

As for

• mips-elf-gcc-4.8.2
• avr-gcc-4.8.1
• msp430-gcc-4.6.3

these calls get into the .ctors section:

.ctors 0x000000009d011508 0x4 libmotor.o

.ctors 0x000000009d01150c 0x4 libaudio.o

---

Compiling was done with -ffunction-sections -fdata-sections, the linker got --gc-sections.

All binaries work, but I'd like to put all calls into the same section (to simplify maintenance of linker scripts).

• Why are there different target sections?
• Is it possible to change the default section using a command line option?
• If a command line option does not exit: Is it possible to define the default section at GCC compile-time?

Answer 1

There is a long discussion in Bug 46770 - Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

I have extracted some items which explain the situation:

Why did .init_array turn up?

• We added .init_array/.fini_array in order to blend the SVR4 version of .init, which contained actual code, with the HP-UX version, which contained function pointers and used a DT_INIT_SZ entry in the dynamic array rather than prologue and epilogue pieces contributed from crt*.o files. The HP-UX version was seen as an improvement, but it wasn't compatible, so we renamed the sections and the dynamic table entries so that the two versions could live side-by-side and implementations could transition slowly from one to the other.

• On HP-UX, we used .init/.init_array for static constructors, and they registered the corresponding static destructors on a special atexit list, rather than adding destructors to .fini_array, so that we could handle destructors on dlclose() events properly (subject to your interpretation of "properly" in that context)

The order of execution differs between .ctors and .init_array

Backwarding order of .ctors section

Some programs may implicitly rely on the fact that global constructors in archives linked later are run before constructors in the object linked against those archives. That is, given

g++ foo.o -lbar

where bar is a static archive, not a shared library, then currently the global constructors in objects pulled in from libbar.c will be executed before the global constructors in foo.o. That was an intentional choice because it is more likely to be correct than the reverse. However, the C++ standard does not guarantee it, so any programs which relies on this ordering is technically invalid.

Problem of backwarding order of .ctors

A lot of work was done in both GNU ld and gold to move constructors from .ctors to .init_array, all to improve startup latency for Firefox

Using .init_array/.fini_array instead of .ctors/.dtors removes the need for the associated (relative) relocations, and avoids the backwards disk seeks on startup (since while .ctors are processed backwards, .init_array is processed forward).

Transition from .ctors to .init_array

The mainline versions of both GNU ld and gold now put .ctors sections into .init_array sections, and put .dtors sections into .fini_array sections.

Comment: Probably introduced with GCC 4.7.

ARM

ARM EABI has been using .init_array from day one.

Comment: Nevertheless the default linker script contains a .ctors output section.

GCC configuration

One option you have is to configure gcc with --disable-initfini-array.

Comment: This option does not turn up in the output of mips-elf-gcc -v (-v shows "Configured with: ...").