This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP/RFC] MIPS registers overhaul


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]