From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9713 invoked by alias); 9 Jun 2003 15:59:25 -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 9699 invoked from network); 9 Jun 2003 15:59:24 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 9 Jun 2003 15:59:24 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h59FxOTA014435 for ; Mon, 9 Jun 2003 11:59:24 -0400 (EDT) Message-ID: <014401c32ea0$18f21830$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "gdb" Subject: register != memory Date: Mon, 09 Jun 2003 15:59:00 -0000 Organization: Netezza Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-06/txt/msg00108.txt.bz2 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. /john