From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32513 invoked by alias); 15 Jul 2003 22:27:03 -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 32505 invoked from network); 15 Jul 2003 22:27:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Jul 2003 22:27:02 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6FMR2H24972 for ; Tue, 15 Jul 2003 18:27:02 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6FMR2I15645; Tue, 15 Jul 2003 18:27:02 -0400 Received: from localhost.localdomain (vpn50-28.rdu.redhat.com [172.16.50.28]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6FMR1P02285; Tue, 15 Jul 2003 18:27:01 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h6FMQu821538; Tue, 15 Jul 2003 15:26:56 -0700 Date: Tue, 15 Jul 2003 22:27:00 -0000 From: Kevin Buettner Message-Id: <1030715222655.ZM21537@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "RFC: Unpredictable register set operations" (Jul 15, 6:09pm) References: <20030715220923.GA30513@nevyn.them.org> To: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: RFC: Unpredictable register set operations MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00177.txt.bz2 On Jul 15, 6:09pm, Daniel Jacobowitz wrote: > Consider PowerPC and the $ps register (MSR). When debugging a kernel or > embedded application, GDB has pretty complete control (?) over this > register. In GNU/Linux userspace, however, only two bits of it can be set. > The rest are read-only. > > So what happens if you "set $ps = 0"? Well, the right thing happens, but > until the next time the target stops "print $ps" will print 0. Which is not > actually the value of the $ps register. > > Here's the options that I see: > - Ignore and document this. > - Refetch registers after storing them. > - Invalidate registers for lazy re-fetch after storing them. > - Add a target hook for might-be-volatile registers, and invalidate > only those registers after storing them - or don't cache them at > all. One of the refetch options (lazy or not) sounds good to me. The target hook idea sounds like overkill, and I think we can do better than "ignore and document". Kevin