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.
