Re: Problem debugging core dump in gdb 7.1 on Solaris x86_64

[Michael Snyder <msnyder@vmware.com>]

Max Kaehn wrote:
> 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

Seems like the only shared library that got loaded was ld.so.

Should more shared libs (eg. libc) be loaded?

Could there be an issue with finding the needed shared libs?



> 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
>