From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16553 invoked by alias); 19 Jan 2008 04:43:57 -0000 Received: (qmail 16545 invoked by uid 22791); 19 Jan 2008 04:43:56 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Jan 2008 04:43:37 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 7EECB98009; Sat, 19 Jan 2008 04:43:35 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 23BA798005; Sat, 19 Jan 2008 04:43:35 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JG5YM-0007ms-0o; Fri, 18 Jan 2008 23:43:34 -0500 Date: Sat, 19 Jan 2008 04:43:00 -0000 From: Daniel Jacobowitz To: Siva Velusamy Cc: gdb@sourceware.org Subject: Re: info on "value being assigned to is no longer active" error Message-ID: <20080119044333.GA29595@caradoc.them.org> Mail-Followup-To: Siva Velusamy , gdb@sourceware.org References: <20080119042116.GA28626@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-01/txt/msg00188.txt.bz2 On Fri, Jan 18, 2008 at 08:26:17PM -0800, Siva Velusamy wrote: > Thanks. Should gdb be able to handle this correctly, or is this a > situation where it is tough to define the correct course of action? > > If gdb should handle this, what sort of change would be appropriate in > the target specific code? The problem is not a target-specific one. I know I've discussed the appropriate fix on the list at some point in the past two years; the problem arises because we use null_frame_id as the ID of the outermost real frame and to mark invalid frames. The simplest fix might be to introduce another invalid frame ID and use that for outermost frames. A better fix would be to always use valid frame IDs, and mark non-unwindable frames some other way. -- Daniel Jacobowitz CodeSourcery