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
