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

["philip.copeland at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

philip.copeland at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
         Resolution|DUPLICATE                   |

--- Comment #7 from philip.copeland at oracle dot com 2013-01-09 01:33:03 UTC ---
Lets see for frame 0 that would be:

[root@localhost ~]# chroot /var/lib/mock/fc18-5/root/
bash-4.2# su - mockbuild
[mockbuild@localhost ~]$ cd  /builddir/build/BUILD/libtool-2.4.2/
[mockbuild@localhost libtool-2.4.2]$ cd tests/testsuite.dir/104/
(gdb) set environment LD_LIBRARY_PATH=m
(gdb) run
Starting program:
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104/.libs/lt-main 
exceptions_in_prog

Program received signal SIGSEGV, Segmentation fault.
0xfffff8010061a558 in __frame_dummy_init_array_entry ()
   from /lib64/libstdc++.so.6
(gdb) disassemble 0xfffff8010061a558
Dump of assembler code for function __frame_dummy_init_array_entry:
   0xfffff8010061a558:  unknown
   0xfffff8010061a55c:  bn  %icc, 0xfffff8010065175c <__ieee754_lgamma_r+2268>
   0xfffff8010061a560:  unknown
   0xfffff8010061a564:  bn  %icc, 0xfffff8010064f264 <__ieee754_j0+612>
   0xfffff8010061a568:  unknown
   0xfffff8010061a56c:  bn  %icc, 0xfffff8010064f36c <__ieee754_j0+876>
   0xfffff8010061a570:  unknown
   0xfffff8010061a574:  bn  %icc, 0xfffff8010064f474 <__ieee754_y0+20>
   0xfffff8010061a578:  unknown
   0xfffff8010061a57c:  bn  %icc, 0xfffff8010064fb7c <qone+92>
   0xfffff8010061a580:  unknown
   0xfffff8010061a584:  bn  %icc, 0xfffff80100650304 <__ieee754_y1+484>
   0xfffff8010061a588:  unknown
   0xfffff8010061a58c:  bn  %icc, 0xfffff80100650a8c <__ieee754_jn+1132>
   0xfffff8010061a590:  unknown
   0xfffff8010061a594:  bn  %icc, 0xfffff80100651014 <__ieee754_lgamma_r+404>
End of assembler dump.

dont think it is a function
(gdb) disassemble __frame_dummy_init_array_entry 
No function contains specified address.
(gdb) whatis __frame_dummy_init_array_entry
type = <data variable, no debug info>
(gdb) print &__frame_dummy_init_array_entry 
$1 = (<data variable, no debug info> *) 0xfffff8010097c150
(gdb) info var __frame_dummy_init_array_entry 
All variables matching regular expression "__frame_dummy_init_array_entry":

Non-debugging symbols:
0x000000000020bd20  __frame_dummy_init_array_entry
0xfffff80100225d78  __frame_dummy_init_array_entry
0xfffff80100329dc0  __frame_dummy_init_array_entry
0xfffff8010042fd80  __frame_dummy_init_array_entry
0xfffff8010061a558  __frame_dummy_init_array_entry
0xfffff80100867d90  __frame_dummy_init_array_entry
0xfffff8010097c150  __frame_dummy_init_array_entry

What does the memory there actually look like?: (assume 8 byte width)
(gdb) x/1xg 0xfffff8010061a558
0xfffff8010061a558:     0xfffff8010048dc80

Ok, since thats a pointer address, where does it lead to? (frame_dummy)
(gdb) disassemble 0xfffff8010048dc80
Dump of assembler code for function frame_dummy:
   0xfffff8010048dc80 <+0>:     save  %sp, -176, %sp
   0xfffff8010048dc84 <+4>:     sethi  %hi(0x5800), %o0
   0xfffff8010048dc88 <+8>:     sethi  %hi(0x192000), %l7
   0xfffff8010048dc8c <+12>:    call  0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff8010048dc90 <+16>:    add  %l7, 0x374, %l7    ! 0x192374
   0xfffff8010048dc94 <+20>:    xor  %o0, -608, %o0
   0xfffff8010048dc98 <+24>:    add  %l7, %o0, %o0
   0xfffff8010048dc9c <+28>:    ldx  [ %o0 ], %g1
   0xfffff8010048dca0 <+32>:    brz,pn   %g1, 0xfffff8010048dcc0
<frame_dummy+64>
   0xfffff8010048dca4 <+36>:    sethi  %hi(0x800), %g1
   0xfffff8010048dca8 <+40>:    xor  %g1, 0x1a8, %g1
   0xfffff8010048dcac <+44>:    ldx  [ %l7 + %g1 ], %g1
   0xfffff8010048dcb0 <+48>:    brz,pn   %g1, 0xfffff8010048dcc0
<frame_dummy+64>
   0xfffff8010048dcb4 <+52>:    nop 
   0xfffff8010048dcb8 <+56>:    call  %g1
   0xfffff8010048dcbc <+60>:    nop 
   0xfffff8010048dcc0 <+64>:    b  %xcc, 0xfffff8010048dba0
<register_tm_clones>
   0xfffff8010048dcc4 <+68>:    restore 
---Type <return> to continue, or q <return> to quit---
   0xfffff8010048dcc8 <+72>:    b,a   %xcc, 0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff8010048dccc <+76>:    nop 
   0xfffff8010048dcd0 <+80>:    nop 
   0xfffff8010048dcd4 <+84>:    nop 
   0xfffff8010048dcd8 <+88>:    nop 
   0xfffff8010048dcdc <+92>:    nop 
End of assembler dump.
(gdb) list frame_dummy
No line number known for frame_dummy.


let me try from the #1 frame above and step forward, see where that is going
(gdb) up
#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0xfffff80100490960 <+0>:     save  %sp, -176, %sp
   0xfffff80100490964 <+4>:     sethi  %hi(0), %o0
   0xfffff80100490968 <+8>:     sethi  %hi(0), %i0
   0xfffff8010049096c <+12>:    sethi  %hi(0x18f400), %l7
   0xfffff80100490970 <+16>:    call  0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff80100490974 <+20>:    add  %l7, 0x290, %l7    ! 0x18f690
   0xfffff80100490978 <+24>:    add  %o0, 8, %o0
   0xfffff8010049097c <+28>:    xor  %i0, 0, %i0
   0xfffff80100490980 <+32>:    call  0xfffff8010061a558
   0xfffff80100490984 <+36>:    add  %l7, %o0, %o0
=> 0xfffff80100490988 <+40>:    add  %o0, %i0, %i0
   0xfffff8010049098c <+44>:    rett  %i7 + 8
   0xfffff80100490990 <+48>:    nop 
End of assembler dump.

-------------------------------------------------------------------------------

Oh you closed this as a dupe? This was rebuilt using gcc-4.7.2-8 recompiled
with itself at the same level.. and looks like the bug you point to is orphaned
by the reporter. Since Tom's report is for a *32* bit problem and mine is for
64 bit It would seem, on balance, likely an endian issue /may/ have creeped in
(sparc is big endian) that or it's something way different. Just thinking out
loud of possibilities

gcc-4.7.2-8.fc18.sparc64
glibc-2.16-28.fc18.sparc64
binutils-2.23.51.0.1-3.fc18.sparc64