Re: [PATCH v5] Fix range end handling of inlined subroutines

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2020-12-29 4:10 a.m., Bernd Edlinger wrote:
> Hi,
> 
> 
> this is a minor update to the previous version here:
> https://sourceware.org/pipermail/gdb-patches/2020-November/173614.html
> 
> The only real change is here:
> 
> --- a/gdb/buildsym.c
> +++ b/gdb/buildsym.c
> @@ -429,7 +429,10 @@ struct block *
>      {
>        m_inline_end_vector.push_back (end_inclusive + 1);
>        if (end_inclusive + 1 == start)
> -       end_inclusive = start;
> +       {
> +         end_inclusive = start;
> +         m_pending_addrmap_interesting = true;
> +       }
>      }
>  
>    if (m_pending_addrmap == nullptr)
> 
> 
> The test case with an empty inline that triggered this
> is from PR 25987.
> 
> It is a real-world code that triggers both an empty inline
> function and the wrong call-stack immediately after
> the inline.  So I added this test case as well.
> 
> So this fixes PR 25987 as well as a lot of issues with
> debugging inlined functions in general.
> 
> 
> Thanks
> Bernd.
> 

I'll look at this patch to try to get the ball rolling, even though I do
not feel qualified at all.

One quick thing, in this change here:

--- a/gdb/testsuite/gdb.cp/step-and-next-inline.exp
+++ b/gdb/testsuite/gdb.cp/step-and-next-inline.exp
@@ -29,16 +29,9 @@ if {[test_compiler_info gcc*] && ![supports_statement_frontiers] } {
 proc do_test { use_header } {
     global srcfile testfile
 
-    if { $use_header } {
-       # This test will not pass due to poor debug information
-       # generated by GCC (at least upto 10.x).  See
-       # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
-       return
-    }
-
     set options {c++ debug nowarnings optimize=-O2}
     if { [supports_statement_frontiers] } {
-       lappend options -gstatement-frontiers
+       lappend options additional_flags=-gstatement-frontiers
     }

You appear to fix a bug in the test where we were missing "additional_flags=",
causing -gstatement-frontiers not to be passed to the compiler.  I think that
fix could be pushed separately immediately.

The issue was introduced in eb24648c453c28f2898fb599311ba004394a8b41 ("Fix
gdb.cp/step-and-next-inline.exp with Clang").

Simon