From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29664 invoked by alias); 20 May 2003 20:32:21 -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 29633 invoked from network); 20 May 2003 20:32:20 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 20 May 2003 20:32:20 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Tue, 20 May 2003 13:32:08 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA18497; Tue, 20 May 2003 13:31:54 -0700 (PDT) Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h4KKWDov014736; Tue, 20 May 2003 13:32:13 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id NAA07758; Tue, 20 May 2003 13:32:12 -0700 (PDT) To: "Andrew Cagney" 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> From: cgd@broadcom.com Date: Tue, 20 May 2003 20:32:00 -0000 In-Reply-To: "Andrew Cagney"'s message of "Tue, 20 May 2003 16:23:34 -0400" Message-ID: MIME-Version: 1.0 X-WSS-ID: 12D44F425972361-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00371.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) (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