From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30905 invoked by alias); 22 Jun 2010 19:21:35 -0000 Received: (qmail 30875 invoked by uid 22791); 22 Jun 2010 19:21:33 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_FD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 19:21:28 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id E679556000; Tue, 22 Jun 2010 12:21:26 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id DE371CD92E; Tue, 22 Jun 2010 12:21:26 -0700 (PDT) Message-ID: <4C210D36.6060908@vmware.com> Date: Tue, 22 Jun 2010 19:21:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Max Kaehn CC: "gdb@sourceware.org" Subject: Re: Problem debugging core dump in gdb 7.1 on Solaris x86_64 References: <4C2109B4.8070708@electric-cloud.com> In-Reply-To: <4C2109B4.8070708@electric-cloud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00103.txt.bz2 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 > > 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: > ... > 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 > > 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: > ... > 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 >