From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-21374-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 11940 invoked by alias); 3 May 2005 13:54:58 -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 11666 invoked from network); 3 May 2005 13:54:08 -0000
Received: from unknown (HELO nevyn.them.org) (66.93.172.17)
  by sourceware.org with SMTP; 3 May 2005 13:54:08 -0000
Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian))
	id 1DSxqi-00063W-BG; Tue, 03 May 2005 09:54:08 -0400
Date: Tue, 03 May 2005 13:54:00 -0000
From: Daniel Jacobowitz <drow@false.org>
To: "Decker, Paul" <Paul.Decker@analog.com>
Cc: gdb@sources.redhat.com
Subject: Re: Value being assigned to is no longer active.
Message-ID: <20050503135408.GA22997@nevyn.them.org>
Mail-Followup-To: "Decker, Paul" <Paul.Decker@analog.com>,
	gdb@sources.redhat.com
References: <E21A9A52FF03B249B20F0DC563DEBB31191D46C9@nwd2exm3.ad.analog.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E21A9A52FF03B249B20F0DC563DEBB31191D46C9@nwd2exm3.ad.analog.com>
User-Agent: Mutt/1.5.8i
X-SW-Source: 2005-05/txt/msg00029.txt.bz2

On Tue, May 03, 2005 at 09:46:40AM -0400, Decker, Paul wrote:
> 
> 
> The "set debug remote 1" and "set debug frame 1" options seem to be good
> things to know.  

Yep.  Please fix your line wrapping; I've manually unwrapped this so
that I can read it.

> { create_sentinel_frame (...) -> {level=-1,type=<unknown> type>,unwind=0x8227310,pc=<unknown>,id={!stack,!code,!special},func=<unknown>} }
> { get_prev_frame_1 (this_frame=-1) -> {level=0,type=<unknown>,unwind=<unknown>,pc=<unknown>,id=<unknown>,func=<unknown>} }
> { deprecated_update_frame_pc_hack (frame=0,pc=0xffa00006) }
> { frame_register_unwind (frame=-1,regnum=49(SP),...) -> *optimizedp=0 *lvalp=2 *addrp=0x8c *bufferp=[f80fb0ff] }
> Sending packet: $mffa00002,c#1b...Ack
> Packet received: 000000000000000000000000
> 0xffa00006 in ?? ()
> (gdb) p/x $PC
> { frame_register_unwind (frame=-1,regnum=0(PC),...) -> *optimizedp=0 *lvalp=2 *addrp=0x0 *bufferp=[0600a0ff] }
> { get_frame_id (fi=0) { frame_register_unwind (frame=-1,regnum=51(FP),...) -> *optimizedp=0 *lvalp=2 *addrp=0x94 *bufferp=[dcb1bc48] }
> { frame_func_unwind (fi=-1) -> 0x0 }
> -> {!stack,!code,!special} }
> $1 = 0xffa00006
> (gdb) set $PC=0xFFA00000
> { frame_register_unwind (frame=-1,regnum=0(PC),...) -> *optimizedp=0 *lvalp=2 *addrp=0x0 *bufferp=[0600a0ff] }
> { frame_id_p (l={!stack,!code,!special}) -> 0 }
> Value being assigned to is no longer active.

The key here is that nothing claims the code at 0xffa00006 as any kind
of frame.  That means we end up with no frames at all except for the
special sentinal frame (at -1).

One solution would be to make sure that some frame sniffer for your
target does accept this frame.  Another would be to handle this in
common code by creating a special frame sniffer, at the end of the
list, which always accepts frame ID 0.  I'm not sure how practical that
is (haven't thought about it much).

-- 
Daniel Jacobowitz
CodeSourcery, LLC