This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: .ctor vs. .init_array ordering


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.


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