This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Debugger support for __float128 type?
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: joseph at codesourcery dot com (Joseph Myers)
- Cc: gcc at gcc dot gnu dot org, gdb at sourceware dot org
- Date: Fri, 2 Oct 2015 18:01:10 +0200 (CEST)
- Subject: Re: Debugger support for __float128 type?
- Authentication-results: sourceware.org; auth=none
Joseph Myers wrote:
> On Fri, 2 Oct 2015, Ulrich Weigand wrote:
> > I see. Well, one could add a DW_ATE_decimal_interchange_float for
> > completeness, if necessary.
>
> Since both DPD and BID are interchange encodings, that doesn't actually
> determine things without some way to say which was used (that is, both
> DW_ATE_decimal_float and DW_ATE_decimal_interchange_float would rely on
> platform-specific information to determine the format). I don't know if
> DW_ATE_decimal_float is being used anywhere for something that's not an
> interchange format.
Ah, yes. I missed that both DPD and BID are defined as interchange
formats. This suggestion doesn't make sense then ...
> > 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
>
> Do you want entirely platform-specific semantics? Or would it be better
> to define standard values to mean it's an IEEE interchange format (or, for
> decimal floating point, to specify whether it's DPD or BID), plus space
> for future standard values and space for platform-specific values?
Hmm, I had been thinking of leaving that entirely platform-specific.
I guess one could indeed define some values with well-defined standard
semantics; that would assume DWARF would want to start getting into the
game of defining floating-point formats -- not sure what the position
of the committee would be on this question ...
[ Back when DW_ATE_decimal_float was added, the initial proposal did
indeed specify the encoding should follow IEEE-754R, but that was
removed when the proposal was actually added to the standard. ]
> Would existing consumers safely ignore that attribute (so that producers
> could safely specify IEEE interchange encoding for float, double etc. if
> applicable, without breaking existing consumers)?
Yes, existing consumers should simply ignore attributes they are not
aware of.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com