This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Problem debugging core dump in gdb 7.1 on Solaris x86_64
- From: Max Kaehn <slothman at electric-cloud dot com>
- To: <gdb at sourceware dot org>
- Date: Tue, 22 Jun 2010 12:06:28 -0700
- Subject: Problem debugging core dump in gdb 7.1 on Solaris x86_64
On a Solaris x86_64 machine:
tempest-solaris% uname -a
SunOS tempest-solaris 5.10 Generic_141445-09 i86pc i386 i86pc Solaris
with a gdb 7.1 configured thusly:
./configure --build=x86_64-pc-solaris2.10 --host=x86_64-pc-solaris2.10
--target=x86_64-pc-solaris2.10
--prefix=/net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10
--with-mpfr=/net/tools/mpfr/2.4.1/i686_SunOS_64.5.10
--with-gmp=/net/tools/gmp/4.3.1/i686_SunOS_64.5.10
--with-tcl=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib
--with-tk=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib --with-expat
--with-libexpat-prefix=/net/tools/expat/2.0.1/i686_SunOS_64.5.10
--with-curses --with-python=no --enable-tui --enable-64bit
--enable-64-bit-bfd
--with-libiconv-prefix=/net/tools/libiconv/1.13.1/i686_SunOS_64.5.10
--with-libintl-prefix=/net/tools/gnu/gettext/0.17/i686_SunOS_64.5.10
--enable-targets=i686-pc-solaris2.10,x86_64-pc-solaris2.10
and built using gcc 4.3.4 configured for i686-pc-solaris2.10 (which
generates functioning amd64 binaries when I build with -m64), I can get
a reasonable stack trace from the core dump from a simple program
("hello, world" + core dump):
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/slothman/Projects/goodbye...done.
[New LWP 1]
Reading symbols from
/net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6...done.
Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6
Reading symbols from /lib/amd64/libm.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/amd64/libm.so.2
Reading symbols from
/net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1...done.
Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1
Reading symbols from /lib/amd64/libc.so.1...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Loaded symbols for /lib/amd64/libc.so.1
Reading symbols from /lib/amd64/ld.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/amd64/ld.so.1
Core was generated by `./goodbye'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000400d17 in main (argc=1, argv=0xfffffd7fffdff848)
at goodbye.cpp:7
7 *p = 0;
but I've been unable to get a sensible stack trace out of a core dump
from a more complex program:
tempest-solaris% /net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10/bin/gdb
/net/chronic2nas/emake-slothman-main/out/i686_SunOS_64.5.10/ecloud/agent/ecagent
/net/chronic2nas/emake-slothman-main/logs-201006211902-solx2-ea2/core
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/net/chronic2nas/emake-slothman-main-201006211520/out/i686_SunOS_64.5.10/ecloud/agent/ecagent...done.
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
[New LWP 5]
Reading symbols from /usr/lib/amd64/ld.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/amd64/ld.so.1
Core was generated by `/opt/ecloud/i686_SunOS.5.10/bin/ecagent
/opt/ecloud/i686_SunOS.5.10/bin/runagen'.
Program terminated with signal 11, Segmentation fault.
#0 0xfffffd7ffeac431c in ?? ()
(gdb) bt
#0 0xfffffd7ffeac431c in ?? ()
Cannot access memory at address 0xfffffd7fffdfed30
(gdb) thread 2
[Switching to thread 2 (LWP 2)]#0 0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0 0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffe1f8dd8
(gdb) thread 3
[Switching to thread 3 (LWP 3)]#0 0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0 0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffdfffd68
(gdb) thread 4
[Switching to thread 4 (LWP 4)]#0 0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0 0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffde00e78
(gdb) thread 5
[Switching to thread 5 (LWP 5)]#0 0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0 0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffdbffc58
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0xfffffd7fff3c1010 0xfffffd7fff3e614e Yes (*) /usr/lib/amd64/ld.so.1
(*): Shared library is missing debugging information.
ldd reports this binary pulls in about 30 shared libraries. I can load
ecagent, type "break main", get a line number for it, and step through
the code when it's live, but I still haven't managed to get gdb to
figure out the core dump.
Is anyone familiar with the arcana of Solaris x86?
Thanks,
Max