On 12/30/20 6:17 PM, Simon Marchi wrote:
> 
> 
> 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.
> 

Yes.  I can do that.

I quickly extracted that one line change as follows.

Is it ok to push?


Thanks
Bernd.