This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
- From: "philip.copeland at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 09 Jan 2013 17:27:18 +0000
- Subject: [Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
- Auto-submitted: auto-generated
- References: <bug-55909-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #33 from philip.copeland at oracle dot com 2013-01-09 17:27:18 UTC ---
Ok,. thats 4.8.0 (gcc-trunk) rebuilt and tested.. fails
bash-4.2# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.8.0/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++ --enable-plugin --with-ppl --with-cloog
--with-long-double-128 --with-cpu=ultrasparc --disable-multilib
--build=sparc64-redhat-linux --disable-initfini-array
Thread model: posix
Breakpoint 1, __cxxabiv1::__cxa_get_globals ()
at ../../.././libstdc++-v3/libsupc++/eh_globals.cc:63
63 { return get_global(); }
(gdb) stepi
0xfffff801001811fc 63 { return get_global(); }
(gdb)
0xfffff80100181200 63 { return get_global(); }
(gdb)
0xfffff80100181204 63 { return get_global(); }
(gdb)
0xfffff8010030e510 in ?? () from /lib64/libstdc++.so.6
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) x/1xg 0xfffff8010030e510
0xfffff8010030e510: 0xfffff8010017dce0
(gdb) disassemble 0xfffff8010017dce0
Dump of assembler code for function
_GLOBAL__sub_I_compatibility_thread_c__0x.cc(void):
0xfffff8010017dce0 <+0>: save %sp, -176, %sp
0xfffff8010017dce4 <+4>: sethi %hi(0x196000), %l7
0xfffff8010017dce8 <+8>: call 0xfffff8010017e4e0
<__sparc_get_pc_thunk.l7>
0xfffff8010017dcec <+12>: add %l7, 0x318, %l7 ! 0x196318
0xfffff8010017dcf0 <+16>: call 0xfffff80100316300
<_ZSt15future_categoryv@plt>
0xfffff8010017dcf4 <+20>: nop
0xfffff8010017dcf8 <+24>: sethi %hi(0x800), %g1
0xfffff8010017dcfc <+28>: xor %g1, 0x50, %g1
0xfffff8010017dd00 <+32>: ldx [ %l7 + %g1 ], %g1
0xfffff8010017dd04 <+36>: stx %o0, [ %g1 ]
0xfffff8010017dd08 <+40>: rett %i7 + 8
0xfffff8010017dd0c <+44>: nop
End of assembler dump.
-------------------------------------------------------------------------------
readelf -S /lib64/libstdc++.so.6
There are 41 section headers, starting at offset 0x584f70:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.build-i NOTE 0000000000000200 00000200
0000000000000024 0000000000000000 A 0 0 4
[ 2] .gnu.hash GNU_HASH 0000000000000228 00000228
0000000000005a1c 0000000000000000 A 3 0 8
[ 3] .dynsym DYNSYM 0000000000005c48 00005c48
0000000000016a58 0000000000000018 A 4 4 8
[ 4] .dynstr STRTAB 000000000001c6a0 0001c6a0
00000000000278e1 0000000000000000 A 0 0 1
[ 5] .gnu.version VERSYM 0000000000043f82 00043f82
0000000000001e32 0000000000000002 A 3 0 2
[ 6] .gnu.version_d VERDEF 0000000000045db8 00045db8
00000000000003f4 0000000000000000 A 4 29 8
[ 7] .gnu.version_r VERNEED 00000000000461b0 000461b0
00000000000000a0 0000000000000000 A 4 3 8
[ 8] .rela.dyn RELA 0000000000046250 00046250
000000000000fc18 0000000000000018 A 3 0 8
[ 9] .rela.plt RELA 0000000000055e68 00055e68
0000000000003e28 0000000000000018 A 3 25 8
[10] .init PROGBITS 0000000000059c90 00059c90
0000000000000048 0000000000000000 AX 0 0 4
[11] .text PROGBITS 0000000000059ce0 00059ce0
00000000000711e0 0000000000000000 AX 0 0 32
[12] .fini PROGBITS 00000000000caec0 000caec0
0000000000000014 0000000000000000 AX 0 0 4
[13] .rodata PROGBITS 00000000000caee0 000caee0
0000000000005e20 0000000000000000 A 0 0 16
[14] .eh_frame_hdr PROGBITS 00000000000d0d00 000d0d00
00000000000048f4 0000000000000000 A 0 0 4
[15] .eh_frame PROGBITS 00000000000d55f8 000d55f8
000000000000eab4 0000000000000000 A 0 0 8
[16] .gcc_except_table PROGBITS 00000000000e40ac 000e40ac
00000000000046ba 0000000000000000 A 0 0 4
[17] .tbss NOBITS 00000000001ea510 000ea510
0000000000000020 0000000000000000 WAT 0 0 8
[18] .init_array INIT_ARRAY 00000000001ea510 000ea510
0000000000000038 0000000000000000 WA 0 0 8
[19] .ctors PROGBITS 00000000001ea548 000ea548
0000000000000010 0000000000000000 WA 0 0 8
[20] .dtors PROGBITS 00000000001ea558 000ea558
0000000000000010 0000000000000000 WA 0 0 8
[21] .jcr PROGBITS 00000000001ea568 000ea568
0000000000000008 0000000000000000 WA 0 0 8
[22] .data.rel.ro PROGBITS 00000000001ea570 000ea570
0000000000005870 0000000000000000 WA 0 0 8
[23] .dynamic DYNAMIC 00000000001efde0 000efde0
0000000000000220 0000000000000010 WA 4 0 8
[24] .got PROGBITS 00000000001f0000 000f0000
0000000000000c00 0000000000000008 WA 0 0 8
[25] .plt PROGBITS 00000000001f0c00 000f0c00
0000000000005360 0000000000000020 WAX 0 0 256
[26] .data PROGBITS 00000000001f5f60 000f5f60
00000000000002d0 0000000000000000 WA 0 0 8
[27] .bss NOBITS 00000000001f6230 000f6230
0000000000014910 0000000000000000 WA 0 0 16
[28] .comment PROGBITS 0000000000000000 000f6230
0000000000000055 0000000000000001 MS 0 0 1
[29] .debug_aranges PROGBITS 0000000000000000 000f6285
000000000000b060 0000000000000000 0 0 1
[30] .debug_info PROGBITS 0000000000000000 001012e5
0000000000219760 0000000000000000 0 0 1
[31] .debug_abbrev PROGBITS 0000000000000000 0031aa45
00000000000264a7 0000000000000000 0 0 1
[32] .debug_line PROGBITS 0000000000000000 00340eec
0000000000043052 0000000000000000 0 0 1
[33] .debug_frame PROGBITS 0000000000000000 00383f40
0000000000000510 0000000000000000 0 0 8
[34] .debug_str PROGBITS 0000000000000000 00384450
000000000005829b 0000000000000001 MS 0 0 1
[35] .debug_loc PROGBITS 0000000000000000 003dc6eb
000000000013a849 0000000000000000 0 0 1
[36] .debug_ranges PROGBITS 0000000000000000 00516f34
000000000006de80 0000000000000000 0 0 1
[37] .gnu.attributes LOOS+ffffff5 0000000000000000 00584db4
0000000000000020 0000000000000000 E 0 0 1
[38] .shstrtab STRTAB 0000000000000000 00584dd4
0000000000000195 0000000000000000 0 0 1
[39] .symtab SYMTAB 0000000000000000 005859b0
000000000001ace8 0000000000000018 40 714 8
[40] .strtab STRTAB 0000000000000000 005a0698
000000000002e401 0000000000000000 0 0 1
so
[10] .init PROGBITS 0000000000059c90 00059c90
[12] .fini PROGBITS 00000000000caec0 000caec0
[18] .init_array INIT_ARRAY 00000000001ea510 000ea510
[25] .plt PROGBITS 00000000001f0c00 000f0c00
exist and .fini_array has vanished (or been renamed)
Let me ask, is it g++ itself that assembles the header or is it passed off to
elfutils or similar? Meanwhile I'll rebuild 4.7.2-8 with
--disable-initfini-array explicitly set though I don't think I'm going to see
much difference.