This is the mail archive of the gdb@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]

Re: i386 register numbering


   Date: Sat, 28 Jul 2001 14:06:43 -0400
   From: Andrew Cagney <ac131313@cygnus.com>

   For the basic FP register, see my recent RFC post about adding 
   builtin_type_floatformat*:

   http://sources.redhat.com/ml/gdb-patches/2001-07/msg00624.html

A few comments then :-):

 * I'm not sure whether "The assertion (TYPE_LENGTH(T) *
   TARGET_CHAR_BIT == TYPE_FLOATFORMAT(T)->totalsize)" should really
   hold.  On the i386 the ISA has a 80-bit extended floating-point,
   while the ABI builds a 80-bit, 96-bit or even 128-bit
   floating-point type on top of it.  Giving the latter three each
   their own floatformat would make it hard to use the floatformat to
   check whether they are equivalent or not.

 * As a consequence TARGET_FLOAT_BIT, TARGET_DOUBLE_BIT, etc. isn't
   really redundant.

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

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

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

   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.

   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.

Mark


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