From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-22584-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 9172 invoked by alias); 20 Sep 2005 16:35:29 -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 9114 invoked by uid 22791); 20 Sep 2005 16:35:19 -0000
Received: from qproxy.gmail.com (HELO qproxy.gmail.com) (72.14.204.192)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 20 Sep 2005 16:35:19 +0000
Received: by qproxy.gmail.com with SMTP id f10so12581qba
        for <gdb@sources.redhat.com>; Tue, 20 Sep 2005 09:35:17 -0700 (PDT)
Received: by 10.64.180.14 with SMTP id c14mr86205qbf;
        Tue, 20 Sep 2005 09:35:17 -0700 (PDT)
Received: by 10.65.20.15 with HTTP; Tue, 20 Sep 2005 09:35:17 -0700 (PDT)
Message-ID: <7f45d939050920093549bc0d9e@mail.gmail.com>
Date: Tue, 20 Sep 2005 16:35:00 -0000
From: Shaun Jackman <sjackman@gmail.com>
Reply-To: Shaun Jackman <sjackman@gmail.com>
To: gdb@sources.redhat.com
Subject: Re: arm-elf-gdb crash
In-Reply-To: <7f45d93905050609033ff95af9@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <7f45d9390505052026171614fd@mail.gmail.com>
	 <20050506033126.GA6920@nevyn.them.org>
	 <7f45d9390505052049550222ec@mail.gmail.com>
	 <20050506040840.GB7038@nevyn.them.org>
	 <7f45d93905050608406479775b@mail.gmail.com>
	 <20050506154214.GA5359@nevyn.them.org>
	 <7f45d93905050609033ff95af9@mail.gmail.com>
X-SW-Source: 2005-09/txt/msg00139.txt.bz2

2005/5/6, Shaun Jackman <sjackman@gmail.com>:
> On 5/6/05, Daniel Jacobowitz <drow@false.org> wrote:
> > GDB associates registers to frames.  It's written to the assumption
> > that there is always a frame; when there isn't, this is just one of
> > many things that is going to go wrong.
>=20
> When the target's gone toes-up like this, normally I don't want to do
> any further source-level debugging. I'm more interested in peeking and
> poking a few registers to do some post-mortem analysis before I reload
> the target. When a frame isn't available, could GDB fall back to a set
> of global registers?
>=20
> Cheers,
> Shaun

Hello,

This is a quick poll to see if there's been any movement on the "Value
being assigned to is no longer active." bug. It haunts me daily.

(gdb) set $cpsr=3D0x1f
Value being assigned to is no longer active.

Cheers!
Shaun