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

[Tom Tromey <tom@tromey.com>]

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

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

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.

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.

Tom