[Bug debug/104194] New: No way to distinguish IEEE and IBM long double in debug info

[Bug debug/104194] New: No way to distinguish IEEE and IBM long double in debug info

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

            Bug ID: 104194
           Summary: No way to distinguish IEEE and IBM long double in
                    debug info
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

With a simple:
long double foo (long double x) { return x; }
long double a;
and compiling with both
-g -O2 -dA -mabi=ibmlongdouble
and
-g -O2 -dA -mabi=ieeelongdouble
shows the same
        .uleb128 0x3     # (DIE (0x42) DW_TAG_base_type)
        .byte   0x10     # DW_AT_byte_size
        .byte   0x4      # DW_AT_encoding
        .4byte  .LASF2   # DW_AT_name: "long double"
base type being used in both cases, yes, there are 2 16 byte type
DW_ATE_floating  types, but guess the debugger needs to differentiate between
the two, because how else would it know how to decode the bits?
It is true that without -mno-gnu-attributes .gnu.attributes is produced, but
with -mno-gnu-attributes it isn't, and e.g. elfutils eu-strip strips
.gnu.attributes into a separate section.  Also relying on DW_AT_producer
doesn't work well, because the -mabi= option can have configured in different
defaults.
On the above testcase there is a small difference:
        .uleb128 0x5     # (DIE (0x67) DW_TAG_formal_parameter)
        .ascii "x\0"     # DW_AT_name
        .byte   0x1      # DW_AT_decl_file (a.c)
        .byte   0x1      # DW_AT_decl_line
        .byte   0x1e     # DW_AT_decl_column
        .4byte  0x42     # DW_AT_type
-       .uleb128 0x8     # DW_AT_location
+       .uleb128 0x2     # DW_AT_location
        .byte   0x90     # DW_OP_regx
-       .uleb128 0x21
-       .byte   0x93     # DW_OP_piece
-       .uleb128 0x8
-       .byte   0x90     # DW_OP_regx
-       .uleb128 0x22
-       .byte   0x93     # DW_OP_piece
-       .uleb128 0x8
+       .uleb128 0x4f
but that just says that the x argument lives in a different location, not all
long double parameters are passed in registers and so there is no way to
distinguish those, similarly there is no way to distinguish automatic or static
variables or function return types.

I'm actually not sure what we should do, whether some new GNU attribute in
addition to the current DW_TAG_base_type attributes, or using some user DW_ATE_
value (pedantically DW_ATE_float is correct for both), DW_AT_digit_count is for
decimal.

Note, there are HP extensions:
/* HP extensions.  */
DW_ATE (DW_ATE_HP_float80, 0x80) /* Floating-point (80 bit).  */
DW_ATE (DW_ATE_HP_complex_float80, 0x81) /* Complex floating-point (80 bit). 
*/
DW_ATE (DW_ATE_HP_float128, 0x82) /* Floating-point (128 bit).  */
DW_ATE (DW_ATE_HP_complex_float128, 0x83) /* Complex fp (128 bit).  */
DW_ATE (DW_ATE_HP_floathpintel, 0x84) /* Floating-point (82 bit IA64).  */
DW_ATE (DW_ATE_HP_imaginary_float80, 0x85)
DW_ATE (DW_ATE_HP_imaginary_float128, 0x86)
DW_ATE (DW_ATE_HP_VAX_float, 0x88) /* F or G floating.  */
DW_ATE (DW_ATE_HP_VAX_float_d, 0x89) /* D floating.  */
DW_ATE (DW_ATE_HP_packed_decimal, 0x8a) /* Cobol.  */
DW_ATE (DW_ATE_HP_zoned_decimal, 0x8b) /* Cobol.  */
DW_ATE (DW_ATE_HP_edited, 0x8c) /* Cobol.  */
DW_ATE (DW_ATE_HP_signed_fixed, 0x8d) /* Cobol.  */
DW_ATE (DW_ATE_HP_unsigned_fixed, 0x8e) /* Cobol.  */
DW_ATE (DW_ATE_HP_VAX_complex_float, 0x8f) /* F or G floating complex.  */
DW_ATE (DW_ATE_HP_VAX_complex_float_d, 0x90) /* D floating complex.  */

but e.g. we use DW_ATE_lo_user aka 0x80 for complex int.

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Maybe we should say what actual mode is used in the DWARF info, not the C
way of getting there?  So something that denotes DP / double-double / QP,
for our three options for long double?

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've mailed a question about this to DWARF public mailing list:
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-January/004859.html

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52277&action=edit
gcc12-pr104194.patch

Untested patch which uses new DW_ATE_* values (DW_ATE_GNU_* ones matching
DW_ATE_HP_* values of similar purpose).

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52277|0                           |1
        is obsolete|                            |

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52280&action=edit
gcc12-pr104194.patch

Updated patch.  The last one didn't work because of duplicate cases.

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Abusing complex fp, what a dastardly plan!  :-)

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:866d73019bd4d1804f7e09409322e6605b81780b

commit r12-6882-g866d73019bd4d1804f7e09409322e6605b81780b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 26 19:42:31 2022 +0100

    dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to
_Float128 [PR104194]

    On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches
wrote:
    > 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.

    Here it is implemented.

    Testcases I've played with are e.g.:
    __ibm128 a;
    long double b;
    _Complex long double c;

    static __attribute__((noinline)) int
    foo (long double d)
    {
      long double e = d + 1.0L;
      return 0;
    }

    int
    main ()
    {
      a = 1.0;
      b = 2.0;
      c = 5.0 + 6.0i;
      return foo (7.0L);
    }
    and
      real(kind=16) :: a
      complex(kind=16) :: b
      a = 1.0
      b = 2.0
    end

    Printing the values of the variables works well,
    p &b or p &c shows pointer to the correct type, just
    ptype b or ptype c prints _Float128 instead of
    long double or complex _Float128 instead of complex long double.
    Even worse in fortran where obviously _Float128 or
    complex _Float128 aren't valid types, but as GDB knows them by name,
    it is just ptype that is weird.

    2022-01-26  Jakub Jelinek  <jakub@redhat.com>

            PR debug/104194
            * dwarf2out.cc (long_double_as_float128): New function.
            (modified_type_die): For powerpc64le IEEE 754 quad long double
            and complex long double emit those as DW_TAG_typedef to
            _Float128 or complex _Float128 base type.

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
A temporary workaround now applied.
The dwarf-discuss thread seems to prefer using separate DW_ATE_* values instead
of DW_AT_precision/DW_AT_minimum_exponent, but hasn't converged yet.

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

[uweigand at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

Ulrich Weigand <uweigand at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uweigand at gcc dot gnu.org

--- Comment #8 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> A temporary workaround now applied.

It turns out this workaround is not transparent to users of the debugger, for
example if you define a variable as
   long double x;
and then issue the "ptype x" command in GDB, you'll now get "_Float128" - which
is quite surprising if you've never even used that type in your source code. 
(This also causes a few GDB test suite failures.)

> The dwarf-discuss thread seems to prefer using separate DW_ATE_* values
> instead of DW_AT_precision/DW_AT_minimum_exponent, but hasn't converged yet.

When I discussed this back in 2017:
https://slideslive.com/38902369/precise-target-floatingpoint-emulation-in-gdb
(see page 16 in the slides), my suggestion was simple
  DW_AT_encoding_variant
which would have the let the details of the floating-point format remain
platform-defined (unspecified by DWARF), but simply allow a platform to define
multiple different formats of the same size if required.