Re: [PATCH v2 8/8] Update .debug_names documentation

[Simon Marchi <simark@simark.ca>]

On 2026-02-10 14:52, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
>>> For a variable to be shared in a PU, either it will just be a
>>> declaration and each including CU will have a separate definition that
>>> refers to it; or alternatively every such variable will have the same
>>> address.  But in the latter case they are the same variable.
> 
> Simon> You can't have a DW_TAG_variable in a PU that will represent a definition
> Simon> in all the included CUs?  For instance, if you have
> 
> Simon>   static const char *my_var;
> 
> Simon> inside a C header file included by many C source files.  And then, in
> Simon> the DWARF, we "factor out" that DW_TAG_variable into a PU that is
> Simon> "DW_TAG_imported_unit"-imported by many CUs.  In that case, wouldn't we
> Simon> have a my_var definition in all CUs?
> 
> This approach would make a different variable in each CU.  They would
> all share a name but have different addresses.  So while it's possible
> to share some of this in a PU (like, the name, type, and source
> location), each CU would still end up with a separate DIE describing the
> address.

Ah, thanks.

> 
> Simon> Ok, so a use case for this would be: the user types "break
> Simon> my_inlined_func", and then you want to find all CUs where
> Simon> my_inlined_func is defined (even through a PU), to find all the inline
> Simon> sites, to put breakpoints on all of them?
> 
> Yes.  That's the failure addressed by the series.

Perfect, thanks.

>>> BTW the DWARF approach to inline functions will also hamper incremental
>>> CU expansion (if we ever get there).  At the very least when finding an
>>> inline function gdb will have to scan all DIEs in the CUs just in case.
> 
> Simon> That's a bummer, I hope we can find a way around this.
> 
> Since the reader pre-loads all the DIEs I am thinking it probably won't
> be super expensive to also iterate over them.  Or alternatively we could
> have the DIE-loading process notice all the spots where an inlined
> function is seen.

I was actually wondering if we could avoid pre-loading all the DIEs from
the start.  But if we need to to a full scan for something like this...

IWBN to measure how long it takes to just read the DIEs, and then to
iterate over all DIEs doing nothing.  Then we'll know if we need to care
about that part or not.

Simon