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 Fri, 16 May 2003 04:00:14 +0000 (UTC), "Andrew Cagney" wrote:
> > Whatever we call them, I think it's still useful to have names
> > associated with them.  E.g, you can do any of the following:
> > 
> >     print $raw_f20
> >     print/x ($raw_f20 >> 32)
> >     set $raw_f20=0xbadbeef
> 
> But how often will that actually happen?
> 
> I think a user debugging o32 on ISA64 still should expect to be 
> manipulating the full 64 bit register.  Only on ISA32 should the 
> registers be restricted to their 32 bit values.
> 
> Even if the upper 32 bits of the FP registers are unpredictable, I think 
> they should still be displayed.

I assume you're talking about manipulating the full 64-bits *only* for
the raw values.  I think there may be issues there, when FR == 0.

When FR == 0, reading and writing doubles from the odd registers in
unpredictable, and reading/writing doubles from the even registers **
must ** include the odd-register value.

So, for instance, when FR = 0, if you read 64 bits of $f12, you'll
get:

	$f12:	0xaaaaaaaabbbbbbbb

That's guarateed.

if you read a single from $f12, you'll get 0xbbbbbbbb, a single from
$f13 you'll get 0xaaaaaaaa.  Likewise, guaranteed.

but if you read a double from $f13, who *knows* what you're going to
get.  You might get:

	$f13:   0x????????aaaaaaaa

but who really knows, and who knows what the ???????? is.

(I think i got my word ordering right in that description.  8-)

When FR==0, there are only two valid ways to read the registers:

	* for i = 0; i < 32; i++
	     <read 32-bits from $i>

	* for i = 0; i < 32; i += 2
	     <read 64-bits from $i>

This MIPS specifications (M64 1.00 Volume I, page 50, section 5.6.2)
indicate that doing 64-bit reads/writes from/to odd FP registers when
FR=0 are "illegal", and that values produced by such operations are
unpredictable.

In other words, if a 64-bit target stub code really is supplying 64
bits of register data when accessing FP registers when FR == 0, then
it's broken.

(If it's attempting to write the odd 64-bit register values back, then
it's *really* broken.)

Heck, if 64-bit target code is even trying to communicate (64 * 8)
bits back when FR == 0, then it's almost certainly broken.  (every
other reigster will be completely unpredictable, and who knows what'll
happen if it tries to write them back if they're changed.)



As an aside, it would probably be good if, when setting a fp register,
e.g.:

	set $f12 = <value>

you were *required* to use one of the union members.

it's kinda weird (uh, quite confusing 8-) to see something like:

	(gdb) info args
	a = -nan(0x7fffff)
	b = 2.20000005
	c = 3.29999995
	d = -4.4000001
	(gdb) info addr b
	Symbol "b" is an argument in register f13.
	(gdb) set $f13 = 3.3
	(gdb) info args
	a = -nan(0x7fffff)
	b = 2.72008302e+23
	c = 3.29999995
	d = -4.4000001

i.e., blind conversion (because "set $f13 = <value>" assumed
incorrectly that you meant "oh, as double") is bad.

(If you're in the situation where you're setting an even register to a
single value, if the n+1 odd reigster also a single value you also
want to do computation on, setting the even as a double could be even
worse...)


cgd


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