[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/15025] --enable-initfini-array creates .init_array where no inpu

From: rguenther at suse dot de
Subject: [Bug ld/15025] --enable-initfini-array creates .init_array where no input has one
Date: Mon, 21 Jan 2013 10:29:57 +0000


--- Comment #6 from rguenther at suse dot de 2013-01-21 10:29:57 UTC ---
amodra at gmail dot com <address@hidden> wrote:

>Alan Modra <amodra at gmail dot com> changed:
>           What    |Removed                     |Added
>                CC|                            |amodra at gmail dot com
>--- Comment #5 from Alan Modra <amodra at gmail dot com> 2013-01-19
>00:17:24 UTC ---
>So it's the 0 terminators from sofini.c that break things when a new
>puts them into .init_array/.fini_array?  Just curious, I'd like to be
>sure I
>understand what is going on here.  See

Yes, that's correct.

>In regard to "minus crtfiles??!!!", this is exactly why those files do
>not have
>their .ctor/.dtor sections placed into .init_array/.fini_array. 
>and .fini_array don't use sentinels and obviously you don't want to try
>execute a function at 0 or -1.

Ok. So to repeat my question. Why merge non-priority .ctor into .init_array at
all? What's the benefit? Why have a configure check for .init_array when the
only situation we have to do sth for correctness is when both
Prioritized .ctor and .init_array appear, and thus obviously .init_array
support can be assumed?

Thus, leave .ctor alone and figure out some other magic to detect if
.init_array.n is present, and only then merge in .ctor.n


Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]