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

[Tom Tromey <tom@tromey.com>]

>>>>> "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.

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.

>> 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.

Tom