From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31717 invoked by alias); 11 Jul 2005 18:47:26 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31371 invoked by uid 22791); 11 Jul 2005 18:47:04 -0000 Received: from palrel11.hp.com (HELO palrel11.hp.com) (156.153.255.246) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 18:47:04 +0000 Received: from cllmail.cup.hp.com (cllmail.cup.hp.com [15.244.92.83]) by palrel11.hp.com (Postfix) with ESMTP id 0B76F32E4; Mon, 11 Jul 2005 11:47:03 -0700 (PDT) Received: from [15.244.95.35] (kh6000.americas.hpqcorp.net [15.244.95.35]) by cllmail.cup.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.04) with ESMTP id LAA26133; Mon, 11 Jul 2005 11:47:02 -0700 (PDT) In-Reply-To: <20050711154926.GB30937@nevyn.them.org> References: <20050711154926.GB30937@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <94cbbbf6ad84e632126e7a0e59830425@cup.hp.com> Content-Transfer-Encoding: 7bit Cc: Andrew STUBBS , GDB From: Marcel Moolenaar Subject: Re: Invalid registers Date: Mon, 11 Jul 2005 18:47:00 -0000 To: Daniel Jacobowitz X-SW-Source: 2005-07/txt/msg00127.txt.bz2 On Jul 11, 2005, at 8:49 AM, Daniel Jacobowitz wrote: > On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote: >> Hi, >> >> I have been having a little trouble updating from GDB 5.3 to GDB 6.3. >> >> It used to be the case that GDB would report '*value not available*' >> (for >> SH - I haven't checked other architectures) if the value of a >> register is >> not known in the current stack frame. However, it no longer does this. >> Since I assume it has not acquired some way to find out what that >> value >> was, I also assume this is somehow broken. > > How's it supposed to know that the value is not available? Given that registers are available when a value has been supplied, it's logical to assume (a priori) that a register is unavailable when no value has been supplied. A register's valid "bit" allows for this since there are 2 states that indicate unavailability: One that indicates a temporary state (0) and one that indicates a permanent state (-1). The initial state of a register is the temporarily unavailable state, which triggers fetching the register from the target. The target can change the state to permanently unavailable or supply the value (it can also, theoretically at least, leave the state unmodified and not provide a value). Hence, the a priori assumption that registers are unavailable when no value has been supplied (i.e. when the valid "bit" is not 1) seems to yield good behaviour when implemented as such. I would say then that gdb knows when a value is not available. Unfortunately, there are various bugs in this respect. A typical bug is to test for (register_valid_p[regnum]) to check if the register is cached, which ignores the <0 state for unavailable. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net