This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: constructor and destructor priority

On Thu, Feb 25, 2010 at 10:42:05PM -0800, Doug Kwan (éæå) wrote:
> The difference is due to use of different initialization mechanism.
> We have .ctors and .dtors on x86 and .init_array and .fini_array on
> ARM.  They are handled a little differently by ld. My question is
> whether this is a specified behaviour or not.  If so, could someone
> point me to the definition?

It's weird.  Entries in .ctors run in reverse order, .dtors in forward
order (see crtbegin, crtend).  The linker sorts the .ctors entries
.ctors, .ctors.1, .ctors.2, .., .ctors.65535.  So the highest priority
ctor is .ctors.65535, corresponding to __attribute__((constructor(1))).
The linker sorts .dtors entries the same way and thus they run in the
opposite order to .ctors, as expected.

As far as I know, .init_array is supposed to run in forward order
and .fini_array in reverse order.  That of course is the opposite
of .ctors/.dtors, and the section names generated by gcc reflect
that.  __attribute__((constructor(1))) gives .init_array.1

So I think there is a bug in the linker, and these two lines:
    KEEP (*(.fini_array))
    KEEP (*(SORT(.fini_array.*)))
should be the other way around.  I'll commit a fix soon.

Alan Modra
Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]