--- Begin Message ---
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: cgd at broadcom dot com
- Cc: Kevin Buettner <kevinb at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Wed, 21 May 2003 11:40:18 -0400
- Subject: Re: [WIP/RFC] MIPS registers overhaul
- Delivery-date: Wed, 21 May 2003 11:48:51 -0400
- Envelope-to: cagney@gnu.org
- References: <1030510002453.ZM3880@localhost.localdomain> <3EBD6131.30209@redhat.com> <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> <mailpost.1053057614.17325@news-sj1-1> <yov5znlma5s9.fsf@broadcom.com> <mailpost.1053123913.16634@news-sj1-1> <yov5wugqa4m8.fsf@broadcom.com> <3ECA8EC6.6030405@redhat.com> <yov5llx1mkab.fsf@broadcom.com>
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
--- End Message ---