From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19079-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 19889 invoked by alias); 17 Aug 2004 13:11:00 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 19876 invoked from network); 17 Aug 2004 13:10:58 -0000
Received: from unknown (HELO nevyn.them.org) (66.93.172.17)
  by sourceware.org with SMTP; 17 Aug 2004 13:10:58 -0000
Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian))
	id 1Bx3ju-00021v-2t; Tue, 17 Aug 2004 09:10:58 -0400
Date: Tue, 17 Aug 2004 13:11:00 -0000
From: Daniel Jacobowitz <drow@false.org>
To: David Lecomber <david@streamline-computing.com>
Cc: gdb@sources.redhat.com
Subject: Re: Opteron Stack Woes
Message-ID: <20040817131057.GA7719@nevyn.them.org>
Mail-Followup-To: David Lecomber <david@streamline-computing.com>,
	gdb@sources.redhat.com
References: <1092744111.3127.25.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1092744111.3127.25.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-SW-Source: 2004-08/txt/msg00226.txt.bz2

On Tue, Aug 17, 2004 at 01:01:51PM +0100, David Lecomber wrote:
> Chaps,
> 
> What's the best way to get enough info to you to help fix some ropey
> stacks that we're seeing on Opteron (SuSE 9), even with the latest CVS?
> 
> Typically we see things like
> 
> (gdb) n
> During symbol reading, Incomplete CFI data; unspecified registers at
> 0x000000000040d7ad.
> 
> and a stacktrace of thousands (and more?) lines
> 
> #0  main__ () at trees.f90:912
> #1  0x00000000004188b8 in __f90_main ()
> #2  0x0000000000418890 in main ()
> #3  0x0000002a95dbbc9e in __libc_start_main () from /lib64/libc.so.6
> #4  0x0000000000400f2a in _start () at ../sysdeps/x86_64/elf/start.S:96
> #5  0x0000007fbffff2a8 in ?? ()
> #6  0x0000000000000000 in ?? ()
> #7  0x0000000000000001 in ?? ()
> #8  0x0000007fbffff5b2 in ?? ()
> #9  0x0000000000000000 in ?? ()
> #10 0x0000007fbffff5f7 in ?? ()
> #11 0x0000007fbffff610 in ?? ()
> #12 0x0000007fbffff654 in ?? ()
> #13 0x0000007fbffff686 in ?? ()
> #14 0x0000007fbffff696 in ?? ()
> #15 0x0000007fbffff6a7 in ?? ()
> #16 0x0000007fbffff6ce in ?? ()
> #17 0x0000007fbffff6de in ?? ()
>  etc...
> 
> Would a readelf -w output assist?  I don't think I can reproduce the
> error with any of the GNU compilers.

readelf -wF is probably your best bet.  But is the only problem the
fact that the backtrace didn't stop at _start?

You might want to investigate why the backtrace didn't stop earlier, at
main or at a fortran entry point.  GDB may be confused about
main_name().

-- 
Daniel Jacobowitz