Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: eliz@is.elta.co.il, gdb@sources.redhat.com
Subject: Re: i386 register numbering
Date: Sat, 28 Jul 2001 15:02:00 -0000	[thread overview]
Message-ID: <200107282202.f6SM27O19318@delius.kettenis.local> (raw)
In-Reply-To: <3B62FF33.2030807@cygnus.com>

   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


  reply	other threads:[~2001-07-28 15:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-28  3:14 Eli Zaretskii
2001-07-28  4:56 ` Mark Kettenis
2001-07-28  5:14   ` Eli Zaretskii
2001-07-28  8:12     ` Andrew Cagney
2001-07-28 10:41       ` Mark Kettenis
2001-07-28 11:06         ` Andrew Cagney
2001-07-28 15:02           ` Mark Kettenis [this message]
2001-07-28 18:06             ` Andrew Cagney
2001-07-28 11:02     ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200107282202.f6SM27O19318@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=ac131313@cygnus.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox