On Wed, 16 Nov 2011, Ian Lance Taylor wrote:
Matt <matt@xxxxxxx> writes:
On Mon, 14 Nov 2011, Ian Lance Taylor wrote:
Matt <matt@xxxxxxx> writes:
libcpp/lex.o differs
What are the differences between stage2-libcpp/lex.o and
stage3-libcpp/lex.o? Ignore the fact that one will have debug info and
the other will not. Look at the readelf -S output for both files, and
see if there are any differences in sections whose names do not start
with ".debug".
in stage2-libcpp/lex.o:
[79] .init_array INIT_ARRAY 0000000000000000 00021280
0000000000000008 0000000000000000 WA 0 0 8
[80] .rela.init_array RELA 0000000000000000 0003a8e8
0000000000000018 0000000000000018 101 79 8
in stage3-libcpp/lex.o:
[79] .ctors PROGBITS 0000000000000000 00021280
0000000000000008 0000000000000000 WA 0 0 8
[80] .rela.ctors RELA 0000000000000000 0003a8e0
0000000000000018 0000000000000018 101 79 8
Thanks. It appears that for some reason your stage2 build is using
--enable-initfini-array while your stage3 build is using
--disable-initfini-array. The default value for this configure option
is set by the configure script.
grep for gcc_cv_initfini_array in stage1-gcc/config.log and
stage2-gcc/config.log. I am guessing that they will have different
values.
yup. stage1 succeeds and stage2 fails, as you predicted.
Look in stage1-gcc/config.log and stage2-gcc/config.log. Look for
"checking for .preinit_array/.init_array/.fini_array support". It
should be followed by a compile and run of conftest. I'm guessing that
one of those runs succeeded and one failed. See if config.log says why.
It *kind of* says why. I've pasted the output below. Unfortunately, when
the full build is finished, the prev-gcc/xgcc no longer exists. When I
test the conftest.c (copied and pasted from the log), the stage1-gcc/xgcc
and stage2-gcc/xgcc have no problem with it (of course).
I did run valgrind on stage1's xgcc and stage2's xgcc, but the only thing
interesting I saw was some branching on unconditional values from data fed
to libz via lto.c:
==9766== Conditional jump or move depends on uninitialised value(s)
==9766== at 0x7035510: inflateReset2 (in
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==9766== by 0x7035605: inflateInit2_ (in
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==9766== by 0x12C0805: lto_end_uncompression (lto-compress.c:277)
==9766== by 0x1223FBF: lto_get_section_data (lto-section-in.c:172)
==9766== by 0x507019: lto_file_finalize (lto.c:1134)
==9766== by 0x5070A6: lto_create_files_from_ids (lto.c:1150)
==9766== by 0x5071BF: lto_file_read (lto.c:1190)
Regardless, here's the output. I'll try another build and "catch" the
build before it removes the prev-gcc/xgcc and try to reproduce the error
there. If you have some ideas in the meantime, let me know.
configure:10965: checking for .preinit_array/.init_array/.fini_array
support
configure:11084: /home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc
-B/home/matt/src/gcc-trunk/obj/./prev-gcc/
-B/home/matt/x86_64-unknown-linux-gnu/bin/
-B/home/matt/x86_64-unknown-linux-gnu/bin/
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem
/home/matt/x86_64-unknown-linux-gnu/include -isystem
/home/matt/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2
-flto=jobserver -frandom-seed=1 -static-libstdc++ -static-libgcc
conftest.c >&5
configure:11084: $? = 0
configure:11084: ./conftest
/home/matt/src/gcc-trunk/gcc/configure: line 1997: 4819 Aborted
./conftest$ac_exeext
configure:11084: $? = 134
configure: program exited with status 134
configure: failed program was:
[...]
PS: I imagine anyone with an Ubuntu 11.10/amd64 installation (or something
similar) would have the same issue. I'll try and reproduce on 11.04 and a
fresh 11.10, as I have time, as well.
--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt
