This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: constructor and destructor priority
- From: Alan Modra <amodra at gmail dot com>
- To: Doug Kwan (éæå) <dougkwan at google dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 26 Feb 2010 21:25:07 +1030
- Subject: Re: constructor and destructor priority
- References: <498552561002252242u16e70d9hdec4a9edf1c981fd@mail.gmail.com>
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