Re: [PATCH 3/3] [gdb/symtab] Tweak fix-up of truncated inline function block ranges

[Tom de Vries <tdevries@suse.de>]

On 3/14/26 3:22 PM, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
> 
>> On 3/10/26 5:05 PM, Andrew Burgess wrote:
>>> Tom de Vries <tdevries@suse.de> writes:
>>>
>>>> Consider test-case gdb.cp/step-and-next-inline.exp on ppc64le-linux.
>>>>
>>>> The corresponding source file step-and-next-inline.cc contains functions
>>>> tree_check and get_alias_set:
>>>> ...
>>>>       35	#define TREE_TYPE(NODE) (*tree_check (NODE, 0))
>>>>       36
>>>>       37	inline tree *
>>>>       38	tree_check (tree *t, int i)
>>>>       39	{
>>>>       40	  if (t->x != i)
>>>>       41	    abort();
>>>>       42	  tree *x = t;
>>>>       43	  return x;
>>>>       44	}
>>>>       ...
>>>>       48	int __attribute__((noinline, noclone))
>>>>       49	get_alias_set (tree *t)
>>>>       50	{
>>>>       51	  if (t != NULL
>>>>       52	      && TREE_TYPE (t).z != 1
>>>>       53	      && TREE_TYPE (t).z != 2
>>>>       54	      && TREE_TYPE (t).z != 3)
>>>>       55	    return 0;
>>>>       56	  return 1;
>>>>       57	}
>>>> ...
>>>> as well as a trivial function main calling get_alias_set.
>>>>
>>>> Say we step into the first call to tree_check, and then step to the return
>>>> at line 43:
>>>> ...
>>>> (gdb) s
>>>> tree_check (i=0, t=0x10020030 <xx>) at step-and-next-inline.cc:40
>>>> 40	  if (t->x != i)
>>>> (gdb) s
>>>> 43	  return x;
>>>> (gdb)
>>>> ...
>>>>
>>>> At that point, we have pc 0x1000071c:
>>>> ...
>>>> (gdb) p $pc
>>>> $1 = (void (*)(void)) 0x1000071c <get_alias_set(tree*)+28>
>>>> (gdb)
>>>> ...
>>>> and the backtrace looks like this:
>>>> ...
>>>>    (gdb) bt
>>>>    #0  tree_check (i=<optimized out>, t=<optimized out>) at
>>>>          step-and-next-inline.cc:43
>>>>    #1  get_alias_set (t=t@entry=0x10020030 <xx>) at step-and-next-inline.cc:52
>>>>    #2  0x0000000010000560 in main () at step-and-next-inline.cc:64
>>>>    (gdb)
>>>> ...
>>>> which shows all 3 functions.
>>>>
>>>> This seems trivial, but it's not.
>>>>
>>>> All three calls to tree_check are inlined, and the first call is represented
>>>> by:
>>>> ...
>>>>    <2><877>: Abbrev Number: 40 (DW_TAG_inlined_subroutine)
>>>>       <878>   DW_AT_abstract_origin: <0x967>
>>>>       <87c>   DW_AT_entry_pc    : 0x10000710
>>>>       <884>   DW_AT_GNU_entry_view: 0
>>>>       <885>   DW_AT_ranges      : 0xc
>>>>       <88a>   DW_AT_call_line   : 52
>>>> ...
>>>> with DW_AT_ranges referring to:
>>>> ...
>>>> Contents of the .debug_rnglists section:
>>>>
>>>>       Offset   Begin    End
>>>>       0000000c 0000000010000710 (base address)
>>>>       00000015 0000000010000710 000000001000071c
>>>>       00000018 000000001000077c 000000001000077c (start == end)
>>>>       0000001b 0000000010000788 0000000010000790
>>>>       0000001f <End of list>
>>>> ...
>>>>
>>>> The range at offset 0x15 is [0x10000710, 0x1000071c), so address 0x1000071c
>>>> does not fall in the range, and consequently the debug info does not consider
>>>> 0x1000071c part of the inlined tree_check.
>>>>
>>>> However, since commit 8efed40efd6 ("gdb: fix-up truncated inline function
>>>> block ranges"), gdb contains a fix in lnp_state_machine::record_line:
>>>> ...
>>>>     if (m_address != m_last_address
>>>>         && m_stmt_at_address
>>>>         && m_cu->producer_is_gcc ()
>>>>         && (m_flags & LEF_IS_STMT) == 0)
>>>>       dwarf_find_and_extend_inline_block_range (m_cu, m_last_address,
>>>>                                                 m_address, m_line);
>>>> ...
>>>> that looks at the corresponding line number information:
>>>> ...
>>>> File name                    Line number    Starting address    View    Stmt
>>>> step-and-next-inline.cc               42          0x1000071c               x
>>>> step-and-next-inline.cc               43          0x1000071c       1       x
>>>> step-and-next-inline.cc               43          0x1000071c       2
>>>> step-and-next-inline.cc               52          0x1000071c       3
>>>> step-and-next-inline.cc               52          0x10000720
>>>> ...
>>>> and extends the range of the inlined tree_check to include
>>>> [0x1000071c, 0x10000720).
>>>>
>>>> [ Please read the commit message of aforementioned commit to understand why
>>>> the fix is correct. ]
>>>>
>>>> Let's look in more detail at how the call to
>>>> dwarf_find_and_extend_inline_block_range is activated for the fix.  It's
>>>> activated for the last entry (52/0x10000720), with:
>>>> - m_last_address == 0x1000071c,
>>>> - m_address == 0x10000720, and
>>>> - m_line == 52 (matching the DW_AT_call_line).
>>>>
>>>> It's easy to see that for the last entry, (m_flags & LEF_IS_STMT) == 0 holds,
>>>> because it doesn't have an x in the "Stmt" column.
>>>>
>>>> I found it less obvious that m_stmt_at_address also holds.
>>>>
>>>> [ The documentation clarifies that this is related to m_last_address:
>>>> ....
>>>>     /* Set to true when a previous line at the same address (using
>>>>        m_last_address) had LEF_IS_STMT set in m_flags.  This is reset to false
>>>>        when a line entry at a new address (m_address different to
>>>>        m_last_address) is processed.  */
>>>>     bool m_stmt_at_address = false;
>>>> ...
>>>>
>>>> To get maximum clarity, I checked the value for each entry:
>>>> ...
>>>> address         m_stmt_at_address
>>>> ---------------------------------
>>>> before          false
>>>> 42/0x1000071c   false->true
>>>> 43/0x1000071c/1 true
>>>> 43/0x1000071c/2 true
>>>> 52/0x1000071c/3 true
>>>> 52/0x10000720   true->false
>>>> ...
>>>>
>>>> Again it's easy to relate the transitions for particular entries to the "Stmt"
>>>> column.
>>>>
>>>> The tricky bit is that the transition takes place at the end of
>>>> lnp_state_machine::record_line, so while processing entry 52/0x10000720, we
>>>> sample m_stmt_at_address while it's still true. ]
>>>>
>>>> Likewise, the fix works for the second inlined call.
>>>>
>>>> But not for the third.  The debug info has the same problem, but the fix is
>>>> not applied.
>>>>
>>>> The corresponding line info looks slightly different:
>>>> ...
>>>> File name                    Line number    Starting address    View    Stmt
>>>> step-and-next-inline.cc               42          0x1000074c               x
>>>> step-and-next-inline.cc               43          0x1000074c       1       x
>>>> step-and-next-inline.cc               43          0x1000074c       2
>>>> step-and-next-inline.cc               54          0x1000074c       3
>>>> step-and-next-inline.cc               55          0x10000750
>>>> ...
>>>>
>>>> In this case, dwarf_find_and_extend_inline_block_range gets called with:
>>>> - m_last_address == 0x1000074c,
>>>> - m_address == 0x10000750, and
>>>> - m_line == 55,
>>>> but since line 55 doesn't match DW_AT_call_line 54:
>>>> ...
>>>>    <2><918>: Abbrev Number: 44 (DW_TAG_inlined_subroutine)
>>>>       <919>   DW_AT_abstract_origin: <0x967>
>>>>       <91d>   DW_AT_entry_pc    : 0x10000740
>>>>       <925>   DW_AT_GNU_entry_view: 0
>>>>       <926>   DW_AT_low_pc      : 0x10000740
>>>>       <92e>   DW_AT_high_pc     : 0xc
>>>>       <937>   DW_AT_call_line   : 54
>>>> ...
>>>> the fix is not applied.
>>>>
>>>> I'm proposing the following simple tweak, to handle the third inlined call as
>>>> well: instead of using m_line, use m_last_line.
>>>>
>>>> Tested on x86_64-linux and ppc64le-linux.
>>>>
>>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
>>>
>>> Hi Tom,
>>>
>>> Thanks for looking at this failure.  Can you confirm which gcc version
>>> you're using please.  I don't see the same failure on cfarm29 (from gcc
>>> compile farm), using gcc 'gcc (Debian 14.2.0-19) 14.2.0'.  But that
>>> step-and-next-inline test can change behaviour based on compiler
>>> version, so I'm not surprised you're seeing failures on some specific
>>> combinations.
>> Hi Andrew,
>>
>> As stated here ( https://sourceware.org/bugzilla/show_bug.cgi?id=33930#c2 )
>> ...
>>     Used compiler version:
>>     ...
>>     [vries@cfarm120 gdb]$ gcc --version
>>     gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11)
>> ...
>>
>> So I'd try cfarm120.
> 
> Thanks.  Just wanted to say I've not forgotten this patch.  I managed to
> reproduce the failure, and I understand what's going on now.  I'm going
> to think about this some more next week.
> 

Great, thanks for the update.

- Tom

> Thanks,
> Andrew
>