[PATCH v3] Fix range end handling of inlined subroutines - restart

[Bernd Edlinger]

On 11/10/20 6:47 PM, Bernd Edlinger wrote:
> 
> On 11/6/20 5:12 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> I finally found some time to start this patch new, addressing the known
>> issues with the previous attempt, and making it even better than before.
>>
>> This time the approach is that no line infos shall be discarded.  Instead
>> they are marked as weak, but they continue to work completely normal.
>>
>> We no longer depend on the inline function to be in a header file for
>> instance, and the inline-frames always show the correct call frames
>> at the weak lines.
>>
>> When we enter an (invalid) empty subroutine range, we are able to stop there,
>> and see the call stack in the subroutine.
>>
>> Also when we have an is_stmt line at the end of a non-empty subroutine
>> range, we see the call stack including the subroutine, and can step
>> normally.
>>
>> The test case gdb.cp/step-and-next-inline.exp is fully functional again,
>> while Andrew's test cases gdb.dwarf2/dw2-inline-header-*.exp continue
>> to function normally, so this nicely co-exists now.
>>
>>
>> Checked on x86_64-pc-linux-gnu.
>> OK for trunk?
>>
> 
> I have now re-based this patch and improved a scenario when stepping
> through an inline function that consists of multiple sub-ranges
> did not work right, whenever the stepping was crossing a sub-range
> beginning, gdb was again stepping back to the call site, and forth
> again to the next line of the subroutine, as if a new subroutine was
> entered.  I've added a test case which forces a branch a different subrange
> of the "tree_check" function which does not pass with the previous version
> of this patch.
> 
> 

This adds just one small fix to the previous version, that is here:

--- a/gdb/block.c
+++ b/gdb/block.c
@@ -210,7 +210,10 @@ struct symbol *
       if (sal.line != 0 && sal.pc == pc && sal.is_weak)
        {
          const struct block *b2 = find_block_in_blockvector (bl, pc - 1);
-         if (contained_in (b2, b))
+         const struct block *b0 = b;
+         while (BLOCK_SUPERBLOCK (b0) && !BLOCK_FUNCTION (b0))
+           b0 = BLOCK_SUPERBLOCK (b0);
+         if (contained_in (b2, b0))
            b = b2;
        }
       *pblock = b;


It happens occasionally, that an inline block is followed by a lexical
block, but the call stack is in fact always from the inline function.
So ignore any lexical block and use any inline frame ending here,
if it is deeper.

Unfortunatley I was not able to extract a small test case for this.

Attached is the latest version of my patch.

Is it OK for trunk?


Thanks
Bernd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-range-end-handling-of-inlined-subroutines.patch
Type: text/x-patch
Size: 28933 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb-patches/attachments/20201119/ba120b7a/attachment-0001.bin>