From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-35001-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 23025 invoked by alias); 20 Jul 2009 16:18:48 -0000
Received: (qmail 22983 invoked by uid 22791); 20 Jul 2009 16:18:47 -0000
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from aussmtpmrkps320.us.dell.com (HELO aussmtpmrkps320.us.dell.com) (143.166.224.254)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jul 2009 16:18:41 +0000
X-Loopcount0: from 12.110.134.31
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31])   by aussmtpmrkps320.us.dell.com with SMTP; 20 Jul 2009 11:17:25 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19044.38999.406407.233204@pkoning-laptop.lab.equallogic.com>
Date: Mon, 20 Jul 2009 16:18:00 -0000
From: Paul Koning <Paul_Koning@dell.com>
To: schwab@linux-m68k.org
Cc: Catherine.Smith@arrows.demon.co.uk,     gdb@sourceware.org
Subject: Re: Backtracing broken core dumps
References: <8889C7D9C664436F8F547CB15F53C01C@Catherine> 	<m27hy4ac0h.fsf@igel.home>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-07/txt/msg00142.txt.bz2

Excerpt of message (sent 19 July 2009) by Andreas Schwab:
> "Catherine Smith" <Catherine.Smith@arrows.demon.co.uk> writes:
> 
> > I have attempted to find back traces of several core dumps
> > which have resulted from executing damaged pointers to
> > functions, or null pointers to functions.
> > Sometimes a gdb command of the form
> >
> >   set pc=$lr
> >
> > would help, except that gdb says
> >
> >  (gdb) set pc=$lr
> >  You can't do that without a process to debug
> 
> Try using the frame command, passing it the address of the frame you
> want to examine.

How does that work?  I see that option documented, but I can't see how
that would work.  At least not for MIPS, where you need to have a PC
in order to know how to display a frame.

I agree with Daniel, setting PC ought to just work.  (More precisely,
PC and SP, or whatever other registers are needed to walk the
callstack.)   This issue comes up every other month or so, and there
is no good answer at the moment.

   paul