[Bug debug/94474] Incorrect DWARF range information for inlined function

["bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
While there are certainly empty subranges that could be avoided,
there are also completely empty subroutines, which cannot be
avoided without losing the ability to inspect the procedure
variable at this location.  I have one example of that class here:

$ cat empty-inline.cc
/* This testcase is part of GDB, the GNU debugger.

   Copyright 2021 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */

/* PR 25987 */
struct MyClass;
struct ptr {
    MyClass* get() { return t; }     /* line 21 */
    MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
    *(volatile char*)(nullptr) = 1;  /* line 26 */
}
static void intermediate(ptr p) {
    p.get()->call();                 /* line 29 */
}
int main() {
    intermediate(ptr{new MyClass});
}
/* EOF */

$ gcc -g -Og empty-inline.cc

The empty inline I mean is ptr::get():

In the debug info this function looks like this:
 <2><11b>: Abbrev Number: 17 (DW_TAG_inlined_subroutine)
    <11c>   DW_AT_abstract_origin: <0x189>
    <120>   DW_AT_entry_pc    : 0x40113f
    <128>   DW_AT_GNU_entry_view: 2
    <129>   DW_AT_low_pc      : 0x40113f
    <131>   DW_AT_high_pc     : 0x0
    <139>   DW_AT_call_file   : 1
    <13a>   DW_AT_call_line   : 29
    <13b>   DW_AT_call_column : 18
    <13c>   DW_AT_sibling     : <0x14e>
 <3><140>: Abbrev Number: 18 (DW_TAG_formal_parameter)
    <141>   DW_AT_abstract_origin: <0x197>
    <145>   DW_AT_location    : 0x16 (location list)
    <149>   DW_AT_GNU_locviews: 0x14
[...]
 <2><197>: Abbrev Number: 22 (DW_TAG_formal_parameter)
    <198>   DW_AT_name        : (indirect string, offset: 0x2e): this
    <19c>   DW_AT_type        : <0x98>
    <1a0>   DW_AT_artificial  : 1
[...]
Contents of the .debug_loclists section:
[...]
    00000014 v000000000000002 v000000000000004 location view pair

    00000016 v000000000000002 v000000000000004 views at 00000014 for:
             000000000040113f 000000000040113f (DW_OP_implicit_pointer: <0x109>
0)
    00000020 <End of list>

when stepping through the empty subroutine the "this" pointer
and in particular the value of the symbol "t" would be accessible,
like this:

(gdb) s
intermediate (p=...) at empty-inline.cc:29
29          p.get()->call();                 /* line 29 */
(gdb) s
ptr::get (this=<synthetic pointer>)
    at empty-inline.cc:21
21          MyClass* get() { return t; }     /* line 21 */
(gdb) p t
$1 = (MyClass *) 0x416c20

This loclist is of course only accessible when we accept an empty
range as something which may exist at all, thus with my latest
GDB-patch applied:
[0/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179367.html
[1/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179368.html
[2/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179370.html
[3/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179369.html
Currently gdb ignores these subroutine as a kind of nonsense.