From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: eliz@is.elta.co.il, gdb@sources.redhat.com
Subject: Re: i386 register numbering
Date: Sat, 28 Jul 2001 18:06:00 -0000
Message-id: <3B636171.6010201@cygnus.com>
References: <200107281012.GAA02314@delorie.com> <s3izo9pnuac.fsf@soliton.wins.uva.nl> <200107281214.IAA07439@delorie.com> <3B62D68B.6010401@cygnus.com> <200107281741.f6SHfoN19109@delius.kettenis.local> <3B62FF33.2030807@cygnus.com> <200107282202.f6SM27O19318@delius.kettenis.local>
X-SW-Source: 2001-07/msg00402.html

>  * extract_floating and store_floating should indeed be using
>    floatformat instead of lengths to match types.


Do you mean to convert to/from DOUBLEST from/to a target floating point 
representation as specified by floatformat.


>  * Deprecating REGISTER_CONVERT_TO_VIRTUAL isn't possible without
>    significant changes to findvar.c:value_from_register().  See below.


Yes, it requires change.


> As is, the patch will break the i386 target because of the assertion.
> See above.  Apart from these assertions, the patch looks fine though.


The FIXME mentioned that :-)


>    You're saying is that a i386 register is always formatted as 
>    floatformat_i387_ext. Correct?
> 
> If we don't consider MMX, yes indeed!  You can use the FPU for integer
> or BCD arithmetic, but even then the register is formatted as
> floatformat_i387_ext.
> 
> Note that a long double is stored in memory in the same format, with
> two extra bytes of padding.  There is no real conversion done between
> the two.  The two extra bytes of padding are not really part of the
> ISA.  The instructions to load from and store floating-point values
> into memory operate on 80-bit memory blocks.


The change in part works because it treats i387_ext80, i387_ext96 and 
i387_ext128 as different types.  Think of it as a ``purest'' position. 
If code has i387_ext80 but needs i387_ext128 then the conversion sequence:

	DOUBLEST tmp;
	extract_floatformat (&in, &tmp, floatformat_i387_ext80);
	store_floatformat (&tmp, &out, floatformat_i387_ext128);

would be needed.   It may be possible, on some architectures, to tune 
those functions so that the above are implemented using memmov().


>    Consequently, with the above change (and related FIXMEs) in place,
>    all the CONVERT* code could be deleted and instead
>    REGISTER_VIRTUAL_TYPE would just return
>    builtin_type_floatformat_i387_ext and GDB would internaly handle
>    all the conversion problems.
> 
> It seems to me that currently, GDB cannot handle those conversion
> problems without REGISTER_CONVERT_TO_VIRTUAL, and that your FIXMEs
> don't address this.  I discovered today that if the debug info says
> that a variable is a `double' or a `float' and that it lives in a
> register instead of memory, it is REGISTER_CONVERT_VIRTUAL that has to
> do the conversion.  If REGISTER_CONVERT_TO_VIRTUAL isn't available,
> findvar.c:value_from_register() will fail miserably.


value_from_register() will need work.  so will (ulgh) get_saved_register().

For value_from_register(), assuming get_saved_register() provides not 
only the raw bytes but also their type, does the sequence:

	get_saved_register (...., regval, regtype);
	if (register_convertible (regnum))
	  convert from regval/regtype to value_ptr/type
	  using standard GDB value conversion code

appear sufficient.  There are definitly going to be warts.  Check the 
MIPS REGISTER_CONVERT_TO_TYPE.

	Andrew