[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909

--- Comment #38 from philip.copeland at oracle dot com 2013-01-12 14:10:52 UTC ---
Ugh,...
well, the good news is that I can now compile this successfully. I didn't even
need to rebuild gcc. (although I will just to follow through on Eric's
suggestion since I didn't find anything terrifically useful as a test for the
initfini-array elf header sections)

Fedora's glibc does not specifically pass --with-tls, and it is assumed that
this is automatically picked up by the configure script (it isn't but I need to
examine that as to why a bit later)

By forcing --with-tls through the configure script and reinstalling the glibc,
g++ seems to notice glibc supporting tls and generates the code necessary for
it.

The rebuilt gcc-4.7.2-8 without initfini-array support produces the same
testsuite results as previously mentioned in #c10 and #c12


+ CC=/builddir/build/BUILD/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/gcc64
+ CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
++ echo -O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc
++ sed 's/ -Wall / /g'
+ CXXFLAGS='-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
+ XCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ TCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ GCJFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultraspar
c'
+ ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux

<just in case there was some discrepancy with what was passed into configure
and what got built..>

<mock-chroot>[root@localhost ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 


<mock-chroot>[root@localhost tmp]# g++ test.c -o test
<mock-chroot>[root@localhost tmp]# ./test
we are able to write to stderr
<mock-chroot>[root@localhost tmp]#

also works
however,..

<mock-chroot>[root@localhost tmp]# readelf -S  ./test | egrep "init|fini|array"
  [11] .init             PROGBITS         0000000000100628  00000628
  [13] .fini             PROGBITS         0000000000100b60  00000b60
  [17] .init_array       INIT_ARRAY       0000000000200c78  00000c78

.init_array somehow crept into binary despite being specifically disabled. I
dunno if that was supposed to happen but it hasn't shown any ill effect as yet


So my last thoughts are, what exactly do we loose by not supporting
initfini_array on sparc?
--------------------------------------------------------------------------------
(From various googled sources and the gnu install.texi file):
.init_array
    An array of function pointers that contributes to a single initialization
array for the executable or shared object containing the section.

.fini_array
    An array of function pointers that contribute to a single termination array
for the executable or shared object containing the section."

--enable-initfini-array
Force the use of sections {.init_array} and {.fini_array}
(instead of {.init} and {.fini}) for constructors and
destructors.  Option {--disable-initfini-array} has the
opposite effect.  If neither option is specified, the configure script
will try to guess whether the {.init_array} and
{.fini_array} sections are supported and, if they are, use them.
--------------------------------------------------------------------------------

My reading of this is that .fini and .init will do just fine but only support
one function whereas the *_array sections can store numerous functions. I'm
guessing this is a load efficiency saver for the linker but wouldn't affect
normal program execution speed?