Re: Debugger support for __float128 type?

["Ulrich Weigand" <uweigand@de.ibm.com>]

Joseph Myers wrote:
> On Thu, 1 Oct 2015, Ulrich Weigand wrote:
> 
> > The _DecimalN types are already supported by DWARF using a base type with
> > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size.
> 
> Which doesn't actually say whether the DPD or BID encoding is used, but as 
> long as each architecture uses only one that's not a problem in practice.

I see.  Well, one could add a DW_ATE_decimal_interchange_float for
completeness, if necessary.
 
> > For the interchange type, it seems one could define a new encoding,
> > e.g. DW_ATE_interchange_float, and use this together with the
> > appropriate DW_AT_byte_size to identify the format.
> 
> It's not clear to me that (for example) distinguishing float and _Float32 
> (other than by name) is useful in DWARF (and if you change float from 
> DW_ATE_float to DW_ATE_interchange_float that would affect old debuggers - 
> is the idea to use DW_ATE_interchange_float only for the new types, not 
> for old types with the same encodings, so for _Float32 but not float?).  
> But it's true that if you say it's an interchange type then together with 
> size and endianness that uniquely determines the encoding.

So my thinking here was: today, DWARF deliberately does not specify the
details of the floating-point encoding format, so that it doesn't have
to get into all the various formats that exist on all the platforms
supported by DWARF.  That is why a DW_ATE_float encoding simply says;
this is a floating-point number of size N encoded as defined by the
platform ABI.

The new DW_ATE_interchange_float encoding would say instead; this is
a floating-point number of size N encoded as defined by the IEEE
interchange format.

On platforms where the ABI-defined format actually *is* the interchange
format, a DWARF producer would be free to use either DW_ATE_float or
DW_ATE_interchange_float.  This decision could of course take into
consideration compatibility requirements with older debuggers etc.

However, having two encoding definitions would allow platforms to use
both the interchange format and one additional platform-defined
non-interchange format of the same size, if needed.

> > Well, complex types have their own encoding (DW_ATE_complex_float), so we'd
> > have to define the corresponding variants for those as well, e.g.
> > DW_ATE_complex_interchange_float or the like.
> 
> And DW_ATE_imaginary_interchange_float, I suppose.

Right.


As an alternative to specifying the well-defined interchange format,
another option might be to simply add a second DWARF attribute,
e.g. DW_AT_encoding_variant, to floating-point and related base types.
This would simply be an integer with platform-specific semantics.
So DWARF producers could simply describe a type as:
  this is a floating-point number of size N encoded as defined by
  platform ABI encoding variant #V

(If the attribute isn't present, we'd default to variant 0, which
is just the current encoding.)

This would allow an arbitrary number of platform-specific encodings,
any of which might or might not be IEEE-defined formats ...


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com