From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22621 invoked by alias); 9 Jun 2003 16:04:49 -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 22573 invoked from network); 9 Jun 2003 16:04:48 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 9 Jun 2003 16:04:48 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19PP9G-0000F4-00; Mon, 09 Jun 2003 11:05:30 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19PP8Q-0000fp-00; Mon, 09 Jun 2003 12:04:38 -0400 Date: Mon, 09 Jun 2003 16:04:00 -0000 From: Daniel Jacobowitz To: "John S. Yates, Jr." Cc: gdb Subject: Re: register != memory Message-ID: <20030609160437.GA2540@nevyn.them.org> Mail-Followup-To: "John S. Yates, Jr." , gdb References: <014401c32ea0$18f21830$1400a8c0@astral> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014401c32ea0$18f21830$1400a8c0@astral> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00109.txt.bz2 On Mon, Jun 09, 2003 at 11:59:24AM -0400, John S. Yates, Jr. wrote: > Being well into implementation of a remote stub > for an embedded environment I have a few thoughts > to share. > > Foremost among these is gdb's modeling of target > registers. The model seems to presume vanilla > registers (e.g. gprs, fprs, pc, etc). > > To provide the low level access needed by many > of our developers I have exposed many kernel-only > registers via g, G, and P. Sadly the results > leave something to be desired because gdb seems > to believe that it can employ a memory-like model > for caching registers. > > This breaks down when the user sets one of these > kernel-only registers. I have numerous examples > where this results in a corrupted register cache: > - readonly registers > - bits that always read as zero or one > - write-one to clear bits > > Since the G message seems to be associated with > establishing thread state I simply ignore values > for any register that is not multiplexed by the > thread scheduler. > > The P message is more of a problem. Even when > returned an error (e.g. an attempt to modify a > readonly register) gdb reports the error to the > user but still updates its register cache. > > A clean solution might be to allow an alternate > reply to a P message: Rval supplying the value > to be encached. I think we need this in general for G also... I have a wishlist bug report asking for one of the PPC system registers to be updated correctly after setting it, since the kernel filters legally changeable bits. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer