From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19139 invoked by alias); 3 Dec 2004 04:54:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19095 invoked from network); 3 Dec 2004 04:54:34 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 3 Dec 2004 04:54:34 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <2004120304543301100hpjcpe>; Fri, 3 Dec 2004 04:54:34 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 03 Dec 2004 04:54:00 -0000 Subject: Re: RFA: Recognize 'x' in response to 'p' packet From: Paul Schlie To: Steven Johnson CC: Message-ID: In-Reply-To: <41AFEC78.50107@neurizon.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-12/txt/msg00060.txt.bz2 I would have thought that the BFD etc. description of the target machine would have correctly identified the register set the machine supported. (but the desire to support a value of x "un-defined/initialized" may make sense if interfaced to a simulator, if the value of x were a represent-able gdb value, and could propagate through expression evaluations which it presently can't, but would be potentially useful if it could to catch subtle bugs; but it's not clear that was the intent?) > From: Steven Johnson > > The PowerPC is such an example, where the Register response usually > includes floating point registers, but say the MPC860 family doesnt have > them. I would imagine the reason to do it is so that, in future, GDB > can remove from the users view registers that are non existent for a > target, rather than show them as 0's. > > If so, then this would be a necessary first step (identifying such from > the target.) > > Steven > > Paul Schlie wrote: > >>> Jim Blandy >>> * remote.c (fetch_register_using_p): Recognize 'x's for the value >>> of the register as indicating that the register's value is not >>> available. >> >> >> Out of curiosity, under what practical circumstances would the value of a >> register not be accessible? (and if not, shouldn't an error be returned, as >> opposed to an 'x' which is converted to a 0 anyway? Which I've noticed "g" >> packets also assume?)