[Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28004

--- Comment #12 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b9f3fbc9f3453bcb24fece0c46acf581d13d3f64

commit b9f3fbc9f3453bcb24fece0c46acf581d13d3f64
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Aug 6 16:44:17 2021 +0200

    [gdb/symtab] Fix zero address complaint for shlib

    In PR28004 the following warning / Internal error is reported:
    ...
    $ gdb -q -batch \
        -iex "set sysroot $(pwd -P)/repro" \
        ./repro/gdb \
        ./repro/core \
        -ex bt
      ...
     Program terminated with signal SIGABRT, Aborted.
     #0  0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
     [Current thread is 1 (LWP 1762498)]
     #1  0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
     warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
               but not in symtab.)
     warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
               but not in symtab.)
      ...
     #2  0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const
\
       [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
       psymtab, but not in symtab.)

    ) from repro/usr/lib/libstdc++.so.6
    ...

    The warning is about the following:
    - in find_pc_sect_compunit_symtab we try to find the address
      (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
    - that fails, so we try again in the partial symtabs.
    - we find a matching partial symtab
    - however, the partial symtab has a full symtab, so
      we should have found a matching symtab in the first step.

    The addresses are:
    ...
    (gdb) info sym 0x7ff8feb2c218
    __gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
      section .text of repro/usr/lib/libstdc++.so.6
    (gdb) info sym 0x7ff8feb2c21d
    __gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
      section .text of repro/usr/lib/libstdc++.so.6
    ...
    which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
    ...
    $ nm -C  repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
    000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
      [clone .cold]
    ...
    which belong to function __gnu_debug::_Error_formatter::_M_error() in
    /build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.

    The partial symtab that is found for the addresses is instead the one for
    /build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
    incorrect.

    This happens as follows.

    The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset
0x4b50:
    ...
        00004b50 0000000000000000 0000000000000056
        00004b5a 00000000000a4790 00000000000a479c
        00004b64 00000000000a47a0 00000000000a47ac
    ...

    When reading the first range 0x0..0x56, it doesn't trigger the "start
address
    of zero" complaint here:
    ...
          /* A not-uncommon case of bad debug info.
             Don't pollute the addrmap with bad data.  */
          if (range_beginning + baseaddr == 0
              && !per_objfile->per_bfd->has_section_at_zero)
            {
              complaint (_(".debug_rnglists entry has start address of zero"
                           " [in module %s]"), objfile_name (objfile));
              continue;
            }
    ...
    because baseaddr != 0, which seems incorrect given that when loading the
    shared library individually in gdb (and consequently baseaddr == 0), we do
see
    the complaint.

    Consequently, we run into this case in dwarf2_get_pc_bounds:
    ...
      if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
        return PC_BOUNDS_INVALID;
    ...
    which then results in this code in process_psymtab_comp_unit_reader being
    called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
    argument to 1:
    ...
          scan_partial_symbols (first_die, &lowpc, &highpc,
                                cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
    ...
    and consequently, the CU addrmap gets build using address info from the
    functions.

    During that process, addrmap_set_empty is called with a range that includes
    0x9c218 and 0x9c21d:
    ...
    (gdb) p /x start
    $7 = 0x9989c
    (gdb) p /x end_inclusive
    $8 = 0xb200d
    ...
    but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
    ...
        000040ae 00000000000b1ee0 00000000000b200e
        000040b9 000000000009989c 00000000000998c4
        000040c3 <End of list>
    ...
    and neither range includes 0x9c218 and 0x9c21d.

    This is caused by this code in partial_die_info::read:
    ...
                if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                        nullptr, tag))
                 has_pc_info = 1;
    ...
    which pretends that the function is located at addresses 0x9989c..0xb200d,
    which is indeed not the case.

    This patch fixes the first problem encountered: fix the "start address of
    zero" complaint warning by removing the baseaddr part from the condition.
    Same for dwarf2_ranges_process.

    The effect is that:
    - the complaint is triggered, and
    - the warning / Internal error is no longer triggered.

    This does not fix the observed problem in partial_die_info::read, which is
    filed as PR28200.

    Tested on x86_64-linux.

    Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

    gdb/ChangeLog:

    2021-07-29  Simon Marchi  <simon.marchi@polymtl.ca>
                Tom de Vries  <tdevries@suse.de>

            PR symtab/28004
            * gdb/dwarf2/read.c (dwarf2_rnglists_process,
dwarf2_ranges_process):
            Fix zero address complaint.
            * gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test.
            * gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test.
            * gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.