From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 726 invoked by alias); 9 Jun 2003 18:33:55 -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 32637 invoked from network); 9 Jun 2003 18:33:47 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 9 Jun 2003 18:33:47 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DBE4C2B63; Mon, 9 Jun 2003 14:33:44 -0400 (EDT) Message-ID: <3EE4D308.1060308@redhat.com> Date: Mon, 09 Jun 2003 18:33:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John S. Yates, Jr." Cc: gdb Subject: Re: register != memory References: <014401c32ea0$18f21830$1400a8c0@astral> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00110.txt.bz2 > Foremost among these is gdb's modeling of target > registers. The model seems to presume vanilla > registers (e.g. gprs, fprs, pc, etc). After writing to a register, everything is invalidated. Is this not happening? Andrew > 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. > > /john > >