Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <3B636171.6010201@cygnus.com> (raw)
In-Reply-To: <200107282202.f6SM27O19318@delius.kettenis.local>

>  * 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


  reply	other threads:[~2001-07-28 18:06 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
2001-07-28 18:06             ` Andrew Cagney [this message]
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=3B636171.6010201@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@wins.uva.nl \
    /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