From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-21764-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 24559 invoked by alias); 6 Jun 2005 13:59:11 -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 24533 invoked by uid 22791); 6 Jun 2005 13:59:08 -0000
Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 06 Jun 2005 13:59:08 +0000
Received: from drow by nevyn.them.org with local (Exim 4.50)
	id 1DfI7w-00078q-Vp; Mon, 06 Jun 2005 09:58:53 -0400
Date: Mon, 06 Jun 2005 13:59:00 -0000
From: Daniel Jacobowitz <drow@false.org>
To: Joost VandeVondele <jv244@hermes.cam.ac.uk>
Cc: gdb@sources.redhat.com
Subject: Re: gdb 6.3 segfault at stack.c:294
Message-ID: <20050606135852.GB27290@nevyn.them.org>
Mail-Followup-To: Joost VandeVondele <jv244@hermes.cam.ac.uk>,
	gdb@sources.redhat.com
References: <Pine.LNX.4.60.0506061428010.17046@hermes-1.csi.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.60.0506061428010.17046@hermes-1.csi.cam.ac.uk>
User-Agent: Mutt/1.5.8i
X-SW-Source: 2005-06/txt/msg00047.txt.bz2

On Mon, Jun 06, 2005 at 02:44:05PM +0100, Joost VandeVondele wrote:
> The executable is a fortran based one, compiled using NAG's f95 
> (which uses gcc to generate code AFAIK).

GDB is not tested using this compiler; if it generates its own debug
information, it's probably in some way incompatible with GDB.

> Program received signal SIGSEGV, Segmentation fault.
> print_frame_args (func=Variable "func" is not available.
> ) at stack.c:294
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> (gdb) list
> 289                 {
> 290                   struct symbol *nsym;
> 291                   nsym = lookup_symbol
> 292                     (DEPRECATED_SYMBOL_NAME (sym),
> 293                      b, VAR_DOMAIN, (int *) NULL, (struct symtab **) 
> NULL);
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> 295                     {
> 296                       /* There is a LOC_ARG/LOC_REGISTER pair.  This 
> means that
> 297                          it was passed on the stack and loaded into a 
> register,
> 298                          or passed in a register and stored in a stack 
> slot.

Presumably nsym is NULL.  I can't imagine how that happened.


-- 
Daniel Jacobowitz
CodeSourcery, LLC