GCC 11.1.10 ld: warning: .init_array section has zero size

[Chris Packham]

On 18/06/21 4:53 pm, Alan Modra wrote:
> On Fri, Jun 18, 2021 at 03:53:29AM +0000, Chris Packham wrote:
>> On 18/06/21 3:37 pm, Alan Modra wrote:
>>> On Fri, Jun 18, 2021 at 12:49:55AM +0000, Chris Packham wrote:
>>>> On 18/06/21 12:30 pm, Alan Modra wrote:
>>>>> On Thu, Jun 17, 2021 at 09:20:56PM +0000, Chris Packham via Binutils wrote:
>>>>>>>> warning: .init_array section has zero size
>>>>>> I'm in the process of getting a GCC bugzilla account so I was also going
>>>>>> to report there.
>>>>> Before doing that, inspect all of the object files you are linking
>>>>> with readelf -SW.  (Use gcc -v to see the linker command line, and all
>>>>> of the objects/libraries involved, or link with -Wl,-t to have the
>>>>> linker report files it links.)  One or more of them will have a zero
>>>>> size .init_array section.  If they were objects created by gcc from
>>>>> source or supplied with the compiler (crtbegin*.o, crtend*.o) then a
>>>>> gcc bug report is appropriate.  If they are other startup files, libc
>>>>> objects or assembly source objects you probably shouldn't complain
>>>>> about gcc.
>>>>>
>>>> Looks like crtbegin.o has a zero-sized .init_array/.fini_array
>>> OK..  I built mainline gcc and the gcc-11 branch from source just now,
>>> a cross from x86_64-linux to arm-linuxeabi, and those sections have
>>> size 4 in my crtbegin.o files.  For gcc-11 the entry in .init_array
>>> comes from crtstuff.c line 504.
>>>
>>> That datapoint might mean the problem is caused by some patch you have
>>> applied, or it might just be some configuration difference.
>> I've tried dropping all the patches crosstool-ng has for GCC 11.1.0
>> (most are just for compiling on macOS). Same result.
>>
>>> I configure gcc using
>>> --with-sysroot=/home/gnu/arm-linuxeabi --prefix=/usr/local \
>>>     --target=arm-linuxeabi --disable-nls --enable-__cxa_atexit \
>>>     --disable-libsanitizer --enable-decimal-float=no \
>>>     --disable-bootstrap --enable-languages=c,c++
>>>
>> Right now crosstool-ng still uses a 3 pass build so the first two passes
>> use --enable-languages=c
> Yes, understood.  Mine was like your last pass build.
>
>> I do note the following
>>
>> x-tool@063c4281c760:~$ find ./.build/arm-unknown-linux-gnueabi/build/
>> -name config.log | xargs grep -n initfini_array
>> ./.build/arm-unknown-linux-gnueabi/build/build-cc-gcc-final/gcc/config.log:7854:gcc_cv_initfini_array=no
>> ./.build/arm-unknown-linux-gnueabi/build/build-binutils-host-x86_64-build_pc-linux-gnu/ld/config.log:3225:enable_initfini_array='yes'
>> ./.build/arm-unknown-linux-gnueabi/build/build-cc-gcc-core-pass-2/gcc/config.log:7854:gcc_cv_initfini_array=no
>> ./.build/arm-unknown-linux-gnueabi/build/build-cc-gcc-core-pass-1/gcc/config.log:7848:gcc_cv_initfini_array=no
>>
>> crosstool-ng doesn't pass either --enable-initfini-array or
>> --disable-initfini-array relying on the configure guessing.
> Nothing out of the ordinary here.  I see the same.  What was your
> final build configure line?

[DEBUG]    Extra config passed: '--enable-languages=c,c++ 
--with-float=soft --with-pkgversion=crosstool-NG 1.24.0.373_5ab29fb 
--disable-sjlj-exceptions --enable-__cxa_atexit 
--disable-tm-clone-registry --disable-libmudflap --disable-libgomp 
--disable-libssp --disable-libquadmath --disable-libquadmath-support 
--disable-libsanitizer --disable-libmpx 
--with-gmp=/home/x-tool/.build/arm-unknown-linux-gnueabi/buildtools 
--with-mpfr=/home/x-tool/.build/arm-unknown-linux-gnueabi/buildtools 
--with-mpc=/home/x-tool/.build/arm-unknown-linux-gnueabi/buildtools 
--with-isl=/home/x-tool/.build/arm-unknown-linux-gnueabi/buildtools 
--enable-lto --with-host-libstdcxx=-static-libgcc 
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm --enable-threads=posix 
--enable-target-optspace --enable-plugin --enable-gold --disable-nls 
--disable-multilib

I wonder if --disable-tm-clone-registry is relevant. That seems to touch 
something in the vicinity of the code you pointed to in crcstuff.c.