When --enable-initfini-array then the linker script looks like .init_array : { KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))) KEEP (*(.init_array)) KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors)) } which means .init_array is unconditionally generated even if it is not present in any input file (but only .ctors are). That's undesirable because it does not preserve ordering in .ctors. Testcase: class X { public: X() {} }; X x; int main(){}
It is done on purpose since .ctors is replaced by .init_array which does preserve order of .ctors within the same file as well as .ctors with priority. It doesn't preserver orders of .ctors sections between different input files. If a program depends on linking order of input files, you can switch the order of input files at command-line.
It breaks building glibc for example. What's the technical reason to force this change at link-time whenever ld.so on the build system supported .init_array? The only reason I can see is for input files that mix .ctor.N and .init_array.N - for correctness you need to merge them. But merging .ctors into .init_array is not required for anything. So, why is this not at least .init_array : { KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))) KEEP (*(.init_array)) } thus not put .ctors (minus crtfiles??!!!) in .init_array. It still will rewrite all-.ctor.N inputs to .init_array which I consider broken, too. But I'm not sure one can conditionalize .init_array output on .init_array input section presence in the linker script. This bug forces us to use --disable-initfini-array which breaks mixed .ctor.N / .init_array.N input file support (which was the whole point of the excercise).
(In reply to comment #2) > It breaks building glibc for example. > I have no problem with glibc build. Do you have a bug report for glibc build failure?
(In reply to comment #2) > It breaks building glibc for example. > Does your glibc have this change: http://sourceware.org/ml/libc-alpha/2010-12/msg00051.html
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 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.
amodra at gmail dot com <sourceware-bugzilla@sourceware.org> 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.
.ctors/.dors section aren't standard. We are removing their support from Linux run-time. The existing DSOs and shared objects still work correctly. All their inputs are converted to gABI.
"hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org> wrote: >http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > >--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-22 >17:09:57 UTC --- >.ctors/.dors section aren't standard. We are removing >their support from Linux run-time. The existing DSOs >and shared objects still work correctly. All their >inputs are converted to gABI. And the point is...? It's not the job of the linker to do this. Btw. You are keeping .ctor anyway because of the Crtfile exception! It doesn't make any sense to me.
I checked GCC 4.7. There are no .ctor/.dtor sections in crtbegin nor crtend files when init-arrary section is enabled. We do this way to support older GCCs which doesn't use init-array sections.
"hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org> wrote: >http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > >--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-22 >20:47:08 UTC --- >I checked GCC 4.7. There are no .ctor/.dtor sections in crtbegin >nor crtend files when init-arrary section is enabled. We do this >way to support older GCCs which doesn't use init-array sections. I am using gcc 4.3. Why should binutils or mess with my .ctor sections without good reason?
New binutils places input .ctor in .init_array to conform to gABI. I have no problems with GCC 4.1 to 4.6.
"hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org> wrote: >http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > >--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-23 >14:34:09 UTC --- >New binutils places input .ctor in .init_array to >conform to gABI. As I still have crtfiles with .ctor with gcc 4.3 the end result does not "conform to gABI" So what is the point of the exercise? I have no problems with GCC 4.1 >to 4.6. I have the issue that new binutils can no longer be used to link old glibc. And whatelse unknown for our ISVs. So I have to disable this "feature" in glibc. Which forces me to disable is also in gcc 4.7 as I lost the feature Of correctly handling mixed prioritized .ctor And .init_array sections. The situation is highly undesirable to me And I question the value of this feature if The resulting object does not conform to gABI
Please clarify your problem, glibc or GCC. I have no problems to use new linker with old GCCs to create applications. I have no problems to use new linker with any GCC to create glibc 2.15 or above.
"hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org> wrote: >http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > >--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-23 >15:02:29 UTC --- >Please clarify your problem, glibc or GCC. I have >no problems to use new linker with old GCCs to create >applications. I have no problems to use new linker >with any GCC to create glibc 2.15 or above. I have a Problem linking glibc 2.13 with gcc 4.3 and binutils 2.23
(In reply to comment #14) > > I have a Problem linking glibc 2.13 with gcc 4.3 and binutils 2.23 Have you tried release/2.13/master branch in glibc git?
(In reply to comment #15) > (In reply to comment #14) > > > > I have a Problem linking glibc 2.13 with gcc 4.3 and binutils 2.23 > > Have you tried release/2.13/master branch in glibc git? I have no problems with glibc 2.13 on ia32 and x86-64.
On Fri, 25 Jan 2013, hjl.tools at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > > --- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-25 18:03:12 UTC --- > (In reply to comment #15) > > (In reply to comment #14) > > > > > > I have a Problem linking glibc 2.13 with gcc 4.3 and binutils 2.23 > > > > Have you tried release/2.13/master branch in glibc git? > > I have no problems with glibc 2.13 on ia32 and x86-64. Sorry, it was glibc 2.11.3. Richard.
I backported the fix to glibc 2.11 on hjl/ctor/release/2.11 branch: http://sourceware.org/git/?p=glibc.git;a=commit;h=91a47ba45fc70b7fce405f05b0543296a4509aa1
On Mon, 28 Jan 2013, hjl.tools at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > > --- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-28 19:03:49 UTC --- > I backported the fix to glibc 2.11 on hjl/ctor/release/2.11 branch: > > http://sourceware.org/git/?p=glibc.git;a=commit;h=91a47ba45fc70b7fce405f05b0543296a4509aa1 I don't see how this can fix a binutils bug.
(In reply to comment #19) > > I don't see how this can fix a binutils bug. It should fix your glibc 2.11.3 build problem.
On Tue, 29 Jan 2013, hjl.tools at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=15025 > > --- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-29 16:47:48 UTC --- > (In reply to comment #19) > > > > I don't see how this can fix a binutils bug. > > It should fix your glibc 2.11.3 build problem. I am not convinced my customers will not run into the same issue. It's a binutils bug, it needs a binutils fix.
Only terminators in .ctors/.dtors sections cause the problem, which are provided in compilers and C libraries. We deal with this issue by special case of GCC and fixing glibc source. We haven't seen any other problems since this change was made more than 2 years ago.
I've ran into Bug 19935, which is caused by "Make --enable-initfini-array the default" on an sh-elf / newlib configuration. I this related?
.