This is the mail archive of the 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: gold patch committed: Reverse .ctors in .init_array

Cary Coutant <> writes:

>> Alan pointed out that when a .ctors sections which has multiple words is
>> mapped to a .init_array section, we need to reverse the order of the
>> entries in the .ctors section. ÂThis is because .ctors and .init_array
>> are executed in reverse order, and we don't want the linker to change
>> the order in which the constructors are executed. ÂThe same applies to
>> .dtors mapped to .fini_array. ÂThis patch implements that in gold.
>> Committed to mainline.
> I asked about this in the comment string for PR 46770, about HJ's
> patch for ld. The answer there was that the compiler generates a
> single function that calls the constructors in the right order, so it
> wasn't necessary to reverse the contents of the .ctors section. What's
> different here? Will gold and gnu ld give different behavior now?

I don't know what GNU ld does.

g++ generate only a single entry in the .ctors section.  However, for C,
when using __attribute__ ((constructor)), gcc will generate multiple
entries.  And, of course, it is possible to create your own .ctors and
.dtors entries, which is what the test case does.  It seems somewhat
reasonable that since gold is doing such an odd trick of copying .ctors
to .init_array, it should take care to not change the order in which
constructors are run.  That patch will do nothing in the normal case of
.ctors sections created by g++.

Oddly, while DT_INIT_ARRAY has advantages over DT_INIT, the immediate
effort appears to have been started by a misunderstanding.  Some people
seem to think that using .init_array rather than .ctors permits the
kernel to seek forward through the executable (e.g., comment #1 in  However, I am told that this was tested by
simply moving .ctors to .init_array, which of course has the effect of
changing the order in which constructors are run.  Avoiding the backward
seek will not be fixed by gold or GNU ld mapping .ctors into


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