This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: .ctor vs. .init_array ordering
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Thu, 21 Feb 2013 10:39:32 -0800
- Subject: Re: .ctor vs. .init_array ordering
- References: <20130208055956.GD5023@bubble.grove.modra.org>
On Thu, Feb 7, 2013 at 9:59 PM, Alan Modra <amodra@gmail.com> wrote:
> Hi HJ,
> I see your .ctors in .init_array changes do the right thing for
> constructors with a priority attribute. ie. the constructor priority
> attribute is respected regardless of whether gcc generates
> .ctors.NNNNN or .init_array.NNNNN.
>
> This:
> SORT_INIT_ARRAY="KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))"
> is good. What's more, constructors with the same priority will appear
> in object file order regardless of their naming.
>
> However, this:
> KEEP (*(.init_array))
> ${CTORS_IN_INIT_ARRAY}
> which expands to
> KEEP (*(.init_array))
> KEEP (*(EXCLUDE_FILE (<startup file patterns>) .ctors))
> means ld puts all .init_array sections before .ctors sections. So we
> aren't consistent with the priority case.
>
> I know we don't promise anything regarding constructor order across
> TUs except that specified by priority attributes, and that the older
> scheme with .ctors was reverse file order while the new .init_array is
> in file order, but having this further inconsistency is even more
> confusing. So how about the following?
>
> * scripttempl/elf.sc (.init_array, .fini_array): Don't sort all
> .init_array/.fini_array input sections before .ctors/.dtors input
> sections.
> (CTORS_IN_INIT_ARRAY, DTORS_IN_INIT_ARRAY): Adjust to suit.
>
>
Sorry to miss this email. I have no problem with it.
Thanks.
H.J.