Re: Debugger support for __float128 type?

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

Joseph Myers wrote:
> On Wed, 30 Sep 2015, Ulrich Weigand wrote:
> 
> > - Extend the official DWARF standard in some way
> 
> I think you should do this.
> 
> Note that TS 18661-4 will be coming out very soon, and includes (optional) 
> types
> 
> * _FloatN, where N is 16, 32, 64 or >= 128 and a multiple of 32;
> 
> * _DecimalN, where N >= 32 and a multiple of 32;
> 
> * _Float32x, _Float64x, _Float128x, _Decimal64x, _Decimal128x
> 
> so this is not simply a matter of supporting a GNU extension (not that 
> it's simply a GNU extension on x86_64 anyway - __float128 is explicitly 
> mentioned in the x86_64 ABI document), but of supporting an ISO C 
> extension, in any case where one of the above types is the same size and 
> radix as float / double / long double but has a different representation.

Ah, thanks for pointing these out!

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.

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.

However, for the extended types, the standard does not define a storage
size or even a particular encoding, so it's not quite clear how to
handle those.  In theory, two different extended types could even have
the same size ...

On the other hand, in practice on current systems, it will probably be
true that if you look at the set of all of the basic and extended (binary)
types, there will be at most two different encodings for any given size,
one corresponding to the interchange format of that size, and one other;
so mapping those to DW_ATE_float vs. DW_ATE_interchange_float might
suffice.

I'm not sure how to handle an extended decimal format that does not
match any of the decimal interchange formats.  Does this occur in
practice at all?

> (All the above are distinct types in C, and distinct from float, double, 
> long double even if the representations are the same.  But I don't think 
> DWARF needs to distinguish e.g. float and _Float32 other than by their 
> name - it's only the case of different representations that needs 
> distinguishing.  The _Float* and _Float*x types have corresponding complex 
> types, but nothing further should be needed in DWARF for those once you 
> can represent _Float*.)

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.

Bye,
Ulrich

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