[Bug debug/99562] New: Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[Bug debug/99562] New: Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[marxin at gcc dot gnu.org]

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

            Bug ID: 99562
           Summary: Invalid debug info: objdump: Warning: Location list
                    starting at offset 0x9c3 is not terminated.
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, mark at gcc dot gnu.org
  Target Milestone: ---

The following produces an invalid debug info:

cat fsize.ii
template < class, class, class, class = void, class = void > struct expression;
template < class tag, class Arg1, class Arg2 >
struct expression< tag, Arg1, Arg2 > {};
template < class Backend > class number {
public:
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  void operator=(expression< tag, Arg1, Arg2, Arg3, Arg4 > e) {
    do_assign(e, int());
  }
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  number(expression< tag, Arg1, Arg2, Arg3, Arg4 > e) {
    *this = e;
  }
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  void do_assign(expression< tag, Arg1, Arg2, Arg3, Arg4 > e, int) {
    Backend __trans_tmp_3 ;
    eval_multiply(m_backend, __trans_tmp_3, canonical_value(e));
  }
  Backend m_backend;
  Backend canonical_value(number);
};
enum cpp_integer_type { signed_magnitude };
enum cpp_int_check_type { unchecked };
template < unsigned = 0, unsigned = 0, cpp_integer_type = signed_magnitude,
           cpp_int_check_type = unchecked, class = int >
struct Trans_NS_backends_cpp_int_backend;
struct cpp_int_base {
  bool m_alias;
  void allocator();
  cpp_int_base() {
    {
      if (m_alias)
        allocator();
    }
  }
};
template < unsigned, unsigned, cpp_integer_type, cpp_int_check_type, class >
struct Trans_NS_backends_cpp_int_backend : cpp_int_base {};
template < unsigned MinBits1, unsigned MaxBits1, cpp_integer_type SignType1,
           cpp_int_check_type Checked1, class Allocator1, unsigned MinBits2,
           unsigned MaxBits2, cpp_integer_type SignType2,
           cpp_int_check_type Checked2, class Allocator2, unsigned MinBits3,
           unsigned MaxBits3, cpp_integer_type SignType3,
           cpp_int_check_type Checked3, class Allocator3 >
void
eval_multiply(Trans_NS_backends_cpp_int_backend< MinBits1, MaxBits1, SignType1,
                                                 Checked1, Allocator1 >,
              Trans_NS_backends_cpp_int_backend< MinBits2, MaxBits2, SignType2,
                                                 Checked2, Allocator2 >,
              Trans_NS_backends_cpp_int_backend< MinBits3, MaxBits3, SignType3,
                                                 Checked3, Allocator3 >) {
  Trans_NS_backends_cpp_int_backend<> t0;
  __int128 limb_max = ~static_cast< unsigned long >(0);
}
class FSize {
  number< Trans_NS_backends_cpp_int_backend<> > _size;
  FSize();
};
expression< int, int, int > __trans_tmp_13;
FSize::FSize() : _size(__trans_tmp_13) {}

$ g++ -gdwarf-4 fsize.ii -c -g -O && objdump -g fsize.o >/dev/null
objdump: Warning: Location list starting at offset 0x9c3 is not terminated.
objdump: Warning: There is a hole [0x9f9 - 0xa0f] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xa8b is not terminated.
objdump: Warning: There is a hole [0xac1 - 0xad7] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xb53 is not terminated.
objdump: Warning: There is a hole [0xb89 - 0xb9f] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xc1b is not terminated.
objdump: Warning: There is a hole [0xc51 - 0xc67] in .debug_loc section.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-12
             Status|UNCONFIRMED                 |NEW

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed:
.LLST40:
        .quad   .LVL14  # Location list begin address (*.LLST40)
        .quad   .LVL24  # Location list end address (*.LLST40)
        .value  0x12    # Location expression size
        .byte   0x9e    # DW_OP_implicit_value
        .uleb128 0x10
        .quad   0xffffffffffffffff
        .quad   .LVL46  # Location list begin address (*.LLST40)
        .quad   .LFE14  # Location list end address (*.LLST40)
We say that the implicit value is 16 byte but only supply 8-byte value.
Looking.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Caused by the (IMHO incorrect) PR66728 changes.
We have 2 spots that fill in dw_loc_oprnd?.v.val_wide:
          mem_loc_result = new_loc_descr (dwarf_OP (DW_OP_const_type), 0, 0);
          mem_loc_result->dw_loc_oprnd1.val_class = dw_val_class_die_ref;
          mem_loc_result->dw_loc_oprnd1.v.val_die_ref.die = type_die;
          mem_loc_result->dw_loc_oprnd1.v.val_die_ref.external = 0;
          mem_loc_result->dw_loc_oprnd2.val_class
            = dw_val_class_wide_int;
          mem_loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc<wide_int> ();
          *mem_loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl, mode);
and
          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);
and 3 callers of add_AT_wide:
    case CONST_WIDE_INT:
      {
        wide_int w1 = rtx_mode_t (rtl, MAX_MODE_INT);
        unsigned int prec = MIN (wi::min_precision (w1, UNSIGNED),
                                 (unsigned int)CONST_WIDE_INT_NUNITS (rtl) *
HOST_BITS_PER_WIDE_INT);
        wide_int w = wi::zext (w1, prec);
        add_AT_wide (die, DW_AT_const_value, w);
      }
and
      else if (dwarf_version >= 5
               && TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (value))) == 128)
        /* Otherwise represent the bound as an unsigned value with
           the precision of its type.  The precision and signedness
           of the type will be necessary to re-interpret it
           unambiguously.  */
        add_AT_wide (die, attr, wi::to_wide (value));
and
          else
            /* Enumeration constants may be wider than HOST_WIDE_INT.  Handle
               that here.  TODO: This should be re-worked to use correct
               signed/unsigned double tags for all cases.  */
            add_AT_wide (enum_die, DW_AT_const_value, wi::to_wide (value));

Now, I think the PR66728 changes fixed the first add_AT_wide case (iff GET_MODE
(rtl) is VOIDmode only) but at the same time broke all the other 4 cases, which
really expect that the constants in the debug info will have the expected
length.  Some cases like the DW_OP_implicit_value we're hitting here explicitly
on the producer size, as it fills in the size of the constant.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

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

Untested fix.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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.