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
next prev parent 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