[Bug ld/15025] --enable-initfini-array creates .init_array where no input has one

[rguenther at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=15025

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

>http://sourceware.org/bugzilla/show_bug.cgi?id=15025
>
>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
>linker
>puts them into .init_array/.fini_array?  Just curious, I'd like to be
>sure I
>understand what is going on here.  See
>http://sourceware.org/ml/binutils/2011-01/msg00159.html

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. 
>.init_array
>and .fini_array don't use sentinels and obviously you don't want to try
>to
>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

Richard.

-- 
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.