[Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info

[Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info

[uweigand at gcc dot gnu.org]

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

            Bug ID: 66728
           Summary: CONST_WIDE_INT causes corrupted DWARF debug info
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: uweigand at gcc dot gnu.org
  Target Milestone: ---

Compiling the following test case:

__uint128_t test(void)
{
  static const __uint128_t two127 = ((__uint128_t) 1) << 127;

  return two127;
}

on x86_64-linux (or ppc64le-linux) with -O -S -g -dA results in:

        .uleb128 0x2    # (DIE (0x2d) DW_TAG_subprogram)
                        # DW_AT_external
        .long   .LASF3  # DW_AT_name: "test"
[snip]
        .uleb128 0x3    # (DIE (0x4e) DW_TAG_variable)
        .long   .LASF4  # DW_AT_name: "two127"
        .byte   0x1     # DW_AT_decl_file (xxx.i)
        .byte   0x4     # DW_AT_decl_line
        .long   0x61    # DW_AT_type
        .byte   0       # end of children of DIE 0x2d

But abbreviation 3 (used for the 0x4e DIE) reads:
        .uleb128 0x3    # (abbrev code)
        .uleb128 0x34   # (TAG: DW_TAG_variable)
        .byte   0       # DW_children_no
        .uleb128 0x3    # (DW_AT_name)
        .uleb128 0xe    # (DW_FORM_strp)
        .uleb128 0x3a   # (DW_AT_decl_file)
        .uleb128 0xb    # (DW_FORM_data1)
        .uleb128 0x3b   # (DW_AT_decl_line)
        .uleb128 0xb    # (DW_FORM_data1)
        .uleb128 0x49   # (DW_AT_type)
        .uleb128 0x13   # (DW_FORM_ref4)
        .uleb128 0x1c   # (DW_AT_const_value)
        .uleb128 0xa    # (DW_FORM_block1)
        .byte   0
        .byte   0

So the variable DIE should have an DW_AT_const_value attribute encoded as
DW_FORM_block1.  This makes sense, since the variable was optimized away due to
being constant, and the size of the constant is 16 bytes.

However, the code in .debug_info to construct the DIE does not emit any
DW_FORM_block1; in fact, it does not emit *anything* where the
DW_AT_const_value is expected.  This causes the resulting debug info to be
corrupted, and tools operating on this info will emit errors (or even crash).

On ppc64le-linux (but not x86_64-linux), the same problem occurs with GCC 5 as
well.  The difference seems to be that x86_64 in GCC 5 uses a CONST_DOUBLE
instead of a CONST_WIDE_INT to represent that 128-bit constant.

[Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info

[uweigand at gcc dot gnu.org]

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

--- Comment #1 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
A bit of debugging shows that what's going on here is this:

add_const_value_attribute is called with the following constant RTL:
(const_wide_int 0x80000000000000000000000000000000)

The routine then does:
         add_AT_wide (die, DW_AT_const_value,
                      std::make_pair (rtl, GET_MODE (rtl)));

Note that GET_MODE (rtl) is VOIDmode.  This apparently causes creation of a
wide_int value with precision 0:
{<wide_int_storage> = {val = {0, -9223372036854775808, 2}, len = 2, precision =
0}

This seems already wrong, but doesn't quite explain the inconsistent output.

However, dwarf2out.c:get_full_len returns 0 if the precision is 0. 
Subsequently, when the DIE is emitted in output_die, we have:

            int len = get_full_len (*a->dw_attr_val.v.val_wide);
            int l = HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR;
            if (len * HOST_BITS_PER_WIDE_INT > 64)
              dw2_asm_output_data (1, get_full_len (*a->dw_attr_val.v.val_wide)
* l,
                                   NULL);

            if (WORDS_BIG_ENDIAN)
              for (i = len - 1; i >= 0; --i)
                {
                  dw2_asm_output_data (l, a->dw_attr_val.v.val_wide->elt (i),
                                       "%s", name);
                  name = NULL;
                }

When get_full_len is 0, the "if" is false, and thus no length is emitted.  In
addition, the loop count is 0, so nothing is emitted at all.

On the other hand, when the abbrev is emitted, value_format does:

    case dw_val_class_wide_int:
      switch (get_full_len (*a->dw_attr_val.v.val_wide) *
HOST_BITS_PER_WIDE_INT)
        {
        case 8:
          return DW_FORM_data1;
        case 16:
          return DW_FORM_data2;
        case 32:
          return DW_FORM_data4;
        case 64:
          return DW_FORM_data8;
        default:
          return DW_FORM_block1;
        }

so for a length of 0 we fall into the default case and assume DW_FORM_block1.

Any suggestions how to fix those (two?) problems?

[Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Related to bug 31690.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-debug
             Target|                            |ppc64le-*-*, x86_64-*-*
                 CC|                            |rsandifo at gcc dot gnu.org
            Version|unknown                     |5.1.1
   Target Milestone|---                         |5.2
            Summary|CONST_WIDE_INT causes       |[5/6 Regression]
                   |corrupted DWARF debug info  |CONST_WIDE_INT causes
                   |                            |corrupted DWARF debug info

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-07-02
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #1)
> A bit of debugging shows that what's going on here is this:
> 
> add_const_value_attribute is called with the following constant RTL:
> (const_wide_int 0x80000000000000000000000000000000)
>
> The routine then does:
>          add_AT_wide (die, DW_AT_const_value,
>                       std::make_pair (rtl, GET_MODE (rtl)));
> 
> Note that GET_MODE (rtl) is VOIDmode.  This apparently causes creation of a
> wide_int value with precision 0:
> {<wide_int_storage> = {val = {0, -9223372036854775808, 2}, len = 2,
> precision = 0}
> 
> This seems already wrong, but doesn't quite explain the inconsistent output.

Yeah, wide_ints shouldn't have precision 0.  I think the later problems
do follow from that, although like you say there is probably a disconnect
between the way the DIEs are handled as well.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Testing a patch.  It involves tightening the mode of the rtx returned
by rtl_for_decl_location, as well as new asserts, so some fallout is
likely...

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #4)
> Testing a patch.  It involves tightening the mode of the rtx returned
> by rtl_for_decl_location, as well as new asserts, so some fallout is
> likely...

Hi Richard, just a quick ping ...  Were you able to make any progress with
this?

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #6)
> (In reply to rsandifo@gcc.gnu.org from comment #4)
> > Testing a patch.  It involves tightening the mode of the rtx returned
> > by rtl_for_decl_location, as well as new asserts, so some fallout is
> > likely...
> 
> Hi Richard, just a quick ping ...  Were you able to make any progress with
> this?

As expected there was a lot of fallout from trying to tighten the mode.
We just seem to be very loose with our type safety here.  Sometimes the
mode of the value associated with the decl is DECL_MODE, sometimes it's
the result of promote_decl_mode, sometimes it's BLKmode when the DECL_MODE
isn't, sometimes the DECL_MODE is BLKmode when the rtl isn't, etc.
It all turned into a bit of a rathole.

I suppose I'm just going to have to admit defeat and use the type or
mode of the decl only in the case where the rtl is a scalar integer
constant -- which seems very inconsistent.

[Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 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:fc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954

commit r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 22 08:52:04 2021 +0100

    debug: Fix __int128 handling in dwarf2out [PR99562]

    The PR66728 changes broke __int128 handling.
    It emits wide_int numbers in their minimum unsigned precision
    rather than in their full precision.
    The problem is then that e.g. the DW_OP_implicit_value path:
              int_mode = as_a <scalar_int_mode> (mode);
              loc_result = new_loc_descr (DW_OP_implicit_value,
                                          GET_MODE_SIZE (int_mode), 0);
              loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
              loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc<wide_int> ();
              *loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl,
int_mode);
    emits invalid DWARF.  In particular this patch fixes there multiple
    occurences of:
            .byte   0x9e    # DW_OP_implicit_value
            .uleb128 0x10
            .quad   0xffffffffffffffff
    +       .quad   0
            .quad   .LVL46  # Location list begin address (*.LLST40)
            .quad   .LFE14  # Location list end address (*.LLST40)
    where we said the value has 16 byte size but then only emitted 8 byte
value.
    My understanding is that most of the places that use val_wide expect
    the precision they chose (the one of the mode they want etc.), the only
    exception is the add_const_value_attribute case where it deals with
    VOIDmode CONST_WIDE_INTs, for that I agree when we don't have a mode
    we need to fallback to minimum precision (not sure if maximum of
    min_precision UNSIGNED and SIGNED wouldn't be better, then consumers
    would know if it is signed or unsigned by looking at the MSB),
    but that code already computes the precision, just decided to
    create the wide_int with much larger precision (e.g. 512 bit
    on x86_64).

    2021-03-22  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99562
            PR debug/66728
            * dwarf2out.c (get_full_len): Use get_precision rather than
            min_precision.
            (add_const_value_attribute): Make sure add_AT_wide argument has
            precision prec rather than some very wide one.