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

[Simon Marchi <simark@simark.ca>]

On 2026-02-10 11:14, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
>>> +The @code{DW_IDX_parent} for a C-style enumerator does not point at
>>> +the entry for @code{enum} itself, but rather the parent of the type.
>>> +The reason for this is that C-style enumerators are injected into the
>>> +containing scope, and so their name is not qualified by the
>>> +@code{enum}; and furthermore there is no way to distinguish between
>>> +C-style enumerators and @code{enum class}-style enumerators in
>>> +@samp{.debug_names}.
> 
> Simon> Ok, so IIUC: there is a way to distinguish between C enums and C++
> Simon> enum-class enums in the debug info itself, but not in .debug_names.  So
> Simon> there is no way just from the index to tell if an enumerator name should
> Simon> be visible from the enclosing scope of not.
> 
> Simon> It sounds like another fix I could bring up to the committee, if we can
> Simon> find a good solution.
> 
> The gdb fix of changing the parentage seems reasonable.  More on the
> rationale below.
> 
> Simon> So, is putting enumerators in .debug_names an extension to the standard
> Simon> in itself?
> 
> Oh maybe so.
> 
> Simon> I don't really understand the logic of not putting the non-enum-class
> Simon> enumerators in the index.
> 
> Indeed but there are many mysteries in DWARF.
> 
> Perhaps omitting enum class enumerators would be ok.  It might require
> some changes to gdb.  I don't plan to work on this, I barely think the
> indexes are worthwhile any more.
> 
>>> +Similarly, @code{DW_IDX_parent} is omitted for any linkage name
>>> +entries that are written.
> 
> Simon> Is this just an optimization? Because for a linkage name, you don't need
> Simon> to know the parent, since there is not need to build the fully qualified
> Simon> name?
> 
> gdb could of course ignore the parentage of a linkage name entry.
> 
> But my view is that the name table is there not to tell gdb the DIE
> parentage in some abstract way, but instead to indicate the names of
> entities.  That's because I see the index as an enhancement to lookup
> and not as a summary version of the .debug_info.
> 
> This view informs both the enum case and the linkage name case.
> 
> That is, my thought is that the DW_IDX_parent stuff is there to explain
> to the debugger how to do a name lookup -- it describes the names, not
> the DWARF.
> 
> So, a linkage name doesn't have a parent in this sense, because it is
> already a fully-qualified name.  And likewise an ordinary enumerator is
> hoisted into the outer scope.

Ok, so with that in mind, do we even need the DW_IDX_linkage_name
attribute?  Ah, perhaps yes because the consumer needs to know if it
should try to demangle it or not?

>>> +A further special case applies to @code{DW_TAG_inlined_subroutine}
>>> +entries.  An inlined subroutine appearing in a partial unit may be
>>> +inlined in all of the outermost compilation units that directly or
>>> +indirectly include the partial unit.  Therefore, in this case,
>>> +@value{GDBN} will emit a separate index entry for the entry, once for
>>> +each such containing unit.
>>> +@end itemize
> 
> Simon> This question probably relates more to the previous patch, but I don't
> Simon> quite understand why this applies to inlined functions but not to other
> Simon> entities found in the PU.  You'd think that if you have a static
> Simon> (file-local) variable defined in a PU, it means that all including CUs
> Simon> have this variable defined.  So wouldn't you want an entry at that name
> Simon> for all these CUs?
> 
> 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.

You can't have a DW_TAG_variable in a PU that will represent a definition
in all the included CUs?  For instance, if you have

  static const char *my_var;

inside a C header file included by many C source files.  And then, in
the DWARF, we "factor out" that DW_TAG_variable into a PU that is
"DW_TAG_imported_unit"-imported by many CUs.  In that case, wouldn't we
have a my_var definition in all CUs?

> Inline functions are different.  An inline function will have a
> DW_TAG_subprogram DIE somewhere (the CU level or appropriate namespace
> scope or whatever) that is a marker indicating "this function is inlined
> somewhere in this CU".
> 
> If you want to find out where it was inlined, the reader has to scan
> that CU looking for DW_TAG_inlined_subroutine.
> 
> In the dwz case, the marker DIE might well be moved into a PU.  This
> isn't like the variable case because there isn't necessarily an address,
> just an DW_AT_inline on the DIE.
> 
> If this DIE is in a PU, then potentially the function has been inlined
> somewhere in all including CUs.

Ok, so a use case for this would be: the user types "break
my_inlined_func", and then you want to find all CUs where
my_inlined_func is defined (even through a PU), to find all the inline
sites, to put breakpoints on all of them?

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

That's a bummer, I hope we can find a way around this.

Simon