On Mon, Jan 24, 2022 at 11:14:41PM +0100, Mark Wielaard wrote:
> On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote:
> > The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
> > equal to corresponding HP extensions) instead of DW_ATE_float,
> > another possibility would be DW_ATE_GNU_precision attribute on the
> > DW_TAG_base_type that would for these multiple 16-byte float cases
> > (or always) emit a precision (113 for binary128, 106 for double double),
> > yet another one is what Ulrich mentions in his slides
> > (DW_AT_GNU_encoding_variant {0,1}).
> >
> > I didn't get any responses to my dwarf discuss mails yet, on IRC
> > Jason preferred a DW_AT_encoding change while Mark prefered
> > DW_AT_GNU_precision. In any case, all of these are just GNU extensions,
> > if/when DWARF standardizes something else, we can use it for -gdwarf-6
> > or later.
>
> When we try to standardize this (in DWARF6) then I think I prefer
> having a separate attribute which specifies the precision, just like
> we already use DW_AT_byte_size to specify the size. That might also
> help with the different float16 encodings.
>
> But if we need a solution now (for gcc12) then using a new DW_ATE_GNU
> extension seems more practical.
Actually for debuggers, DW_AT_GNU_precision might be better.
I think debuggers will just give up on unknown DW_ATE_*, they really don't
know how to handle it.
While if they see an unknown attribute on the base type, I'd think they'd
ignore it, so treat the IEEE quad "long double" as IBM double double
instead, but e.g. for __float128 or __ibm128 would be using the DW_AT_name
heuristics handled fine.
Yet another short term solution might be not use DW_TAG_base_type
for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
with DW_AT_name "long double" to __float128 DW_TAG_base_type.
I bet gdb would even handle it without any changes, but of course, it would
be larger than the other proposed changes.
Jakub
