From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19692 invoked by alias); 21 May 2003 15:40:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19642 invoked from network); 21 May 2003 15:40:29 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 21 May 2003 15:40:29 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4DEE02B2F; Wed, 21 May 2003 11:40:18 -0400 (EDT) Message-ID: <3ECB9DE2.1020906@redhat.com> Date: Wed, 21 May 2003 15:40: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: cgd@broadcom.com Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul References: <1030510002453.ZM3880@localhost.localdomain> <3EBD6131.30209@redhat.com> <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> <3ECA8EC6.6030405@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00383.txt.bz2 > At Tue, 20 May 2003 16:23:34 -0400, Andrew Cagney wrote: > >> When a 64 bit kernel goes to save/resume an o32 process, how does it do >> it? Does it have a choice? > > > it has limited choice. > > > >> For instance, do a 64 bit FP restore then clear the FR bit; the reverse; >> some other variant; ...? > > > So, if the process is running with FR=0, then the save/restore should > ("must" i believe) be done with FR=0. > > When FR=0, there are two options as to how to do it: > > for (i = 0; i < 32; i++) > move/store word from c1 reg $i (i.e., dmfc1/sdc1) > > OR: > > for (i = 0; i < 32; i += 2) > move/store dword from c1 reg $i (i.e., dmfc1/sdc1) That isn't quite the detail I was looking for. Does the code need to look like: save:: save FSR if (FSR & FR) save 32x32 FP else save 32x64 FP restore:: restore FSR if (FSR & FR) restore 32x32 FP else restore 32x64 FP that is, the FSR[FR] bit (wonder if I've got the names right) needs to set/clear the FR bit before it even starts to consider saving/restoring the other registers. The reverse operation: save:: save FSR make FP registers 64 bit save 32x64 FP restore:: // assume FSR[FR] set to 64 bit mode restore 32x64 FP restore FSR operation not being valid. Andrew > (move to / load for the state restore, of course.) > > (of course, these will typically be written in assembly code, and > "fully unrolled" -- the pseudo-C-code is to demonstrate the concept > only.) > > either one is valid, though all implementations that I know of choose > the latter because it's fewer instructions and almost certainly more > efficient. > > > the linux kernel presents that to o32 userland (o32 ptrace syscall) as > an array of 32 32-bit values, but IIRC it's stored internally as (8 > byte reg, 8 byte pad) * 16. > > > > cgd > >