This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: i386 register numbering
> * 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