From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23883 invoked by alias); 15 Jul 2003 22:09: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 23875 invoked from network); 15 Jul 2003 22:09:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Jul 2003 22:09:24 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19cXzA-0007yW-00 for ; Tue, 15 Jul 2003 18:09:24 -0400 Date: Tue, 15 Jul 2003 22:09:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: RFC: Unpredictable register set operations Message-ID: <20030715220923.GA30513@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00176.txt.bz2 I'm sure this has come up before, but I couldn't find a discussion anywhere so I'll just have to ask again... 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. Thoughts? Is this a problem worth fixing? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer