Re: virtual and raw

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Tue, 4 Apr 2000 15:17:35 -0500 (EST)
   From: Jim Blandy <jimb@zwingli.cygnus.com>

   I'd appreciate it if folks could check my understanding of a certain
   bit of logic in GDB, and its consequences.

   If one is cross-debugging, then the REGISTER_CONVERTIBLE macro
   indicates which registers have values in some format that can't be
   interpreted directly by GDB.  The REGISTER_CONVERT_TO_VIRTUAL and
   REGISTER_CONVERT_TO_RAW macros will convert back and forth between the
   machine's format, and one that GDB can understand.

This also happens for native debugging.

   So, for example, if you are debugging an x86 target from some other
   kind of host which does not support the x86's 80-bit long double type,
   then REGISTER_CONVERTIBLE will indicate that all the floating-point
   registers need conversion, and R_C_T_VIRTUAL and R_C_T_RAW will
   convert between the x86 long double and something the host can handle.

I don't think this is accurate.  The way this stuff is used on x86 now
is to take into account the fact that the x86's floating point
registers (80-bit extended floating-point values) have a different
format than any of the floating point types provided by the compiler
that are known to GDB.  In the past GDB did only know about floats and
doubles, and the macro's converted between the 80-bit extended format
and the 64-bit double format.  Nowadays we convert between the 80-bit
extended format and the 96-bit layout that is used to store a long
double in memory.

Since the 80-bit and 64-bit formats are really different (as opposed
to the 80-bit and 96-bit formats), the old code converted via the
host's `doublest' format.  But don't let this fool you.  Both the
`raw' and the `virtual' values are as the target would see them.

It seems that the way virtual and raw are used on i960 and m68k is
basically the same (except that those targets don't have long double
support and therefore are more similar to the old x86 code).  I don't
know why mips uses the virtual/raw distinction though.

   Am I correct in thinking that, if there is an x86 long double in
   memory, not in a register, then GDB is at present incapable of
   converting that value to a format it can understand?  That is, the
   virtual / raw conversion system is only set up to handle registers, so
   even though the exact same conversions could be usefully applied to
   values in memory, GDB doesn't know how to do them?

The problem you're thinking of seems to be exactly the thing that the
virtual/raw distinction tries to solve: things are laid out differently
in memory than in the registers.  By converting the registers, GDB
only has to deal with the way these variables are stores in memory,
which simplifies things considerably.

Of course one can imagine that one store's things that are in register
layout into memory.  To handle that, one would simply add the
necessary type to GDB (and probably not use the virtual/raw
distinction at all).

In the case of the x86 80-bit extended floats this can indeed be done
(the Free Pascal Compiler seems to do this).  However introducing
another floating point type is rather painful since there are several
places in GDB where it is assumed that there are only three different
floating-point types.

Mark