From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23152 invoked by alias); 12 Jul 2005 17:19:00 -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 23130 invoked by uid 22791); 12 Jul 2005 17:18:54 -0000 Received: from palrel13.hp.com (HELO palrel13.hp.com) (156.153.255.238) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 12 Jul 2005 17:18:54 +0000 Received: from cllmail.cup.hp.com (cllmail.cup.hp.com [15.244.92.83]) by palrel13.hp.com (Postfix) with ESMTP id E39FF1C03613; Wed, 13 Jul 2005 11:18:01 -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 KAA03410; Tue, 12 Jul 2005 10:18:52 -0700 (PDT) In-Reply-To: References: <20050711154926.GB30937@nevyn.them.org> <94cbbbf6ad84e632126e7a0e59830425@cup.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0fbda1e85ae826a03ebacd92bcb1f8c2@cup.hp.com> Content-Transfer-Encoding: 7bit Cc: GDB , "Daniel Jacobowitz" From: Marcel Moolenaar Subject: Re: Invalid registers Date: Tue, 12 Jul 2005 17:19:00 -0000 To: Andrew STUBBS X-SW-Source: 2005-07/txt/msg00139.txt.bz2 On Jul 12, 2005, at 9:13 AM, Andrew STUBBS wrote: > On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar > wrote: >> 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. > > Thanks, I did look at this before I posted, but I concluded that I was > not what I was looking for. I mean, how would the target know what > frame you were in? You only ask the target about the current or interrupted state (i.e. frame #0). From that you unwind to the state of the frame in question. I noticed that even in frame #0 all registers were displayed. Even if I marked some of them as unavailable. This of course affects unwinding as well. So, even though I misunderstood the context, the issues are closely related. > I do not know what it means for a register to be invalid in the > target. Might it be because some registers are not available when, for > example, the FPU is disabled? Yes, that could be a possibility. On ia64, for example, the number of stacked registers is variable. gdb currently displays all 96 of them, even if the frame has only 3 stacked registers allocated. Other examples include registers that are simply not exposed through ptrace(2) or saved in core files. That is, the set of registers available to gdb may vary between operating systems. It makes sense for gdb to know about the superset, but it would be nice if it then didn't output 0 values for registers that aren't available as that may cause confusion. BTW: this isn't a big deal, because you can debug your code anyway. It's just (much) nicer to be able to represent reality better. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net