Re: [PATCH v2 7/8] Handle inline functions with dwz

[Simon Marchi <simark@simark.ca>]

On 2026-01-26 16:33, Tom Tromey wrote:
> Currently, gdb does not properly handle inline functions when dwz is
> used.  This can be seen by running gdb.cp/breakpoint-locs.exp with the
> cc-with-dwz target board.
> 
> The problem here is that inline functions need special handling in the
> dwz case.
> 
> First, recall that a DWARF partial unit cannot, in general, be read in
> isolation, as it may not have a language.  To handle this, gdb defers
> scanning partial units directly, and instead scans them in the context
> of some including CU.
> 
> Entries coming from the PU are attributed to this reading CU.  If
> multiple CUs import a PU, gdb has the reader threads race to see which
> one does the actual reading.
> 
> However, if an inline function is moved into a partial unit, then that
> means it has potentially been inlined somewhere in every including CU.
> 
> Thus, when linespec searches for this function, each such including CU
> should be expanded.  But because gdb only attributed the function's
> index entry to one CU, only that particular one is expanded.
> 
> This patch fixes this bug.  All inclusions of a PU are recorded.
> Entries coming from a PU are attributed to that PU.  For most entries
> coming from the PU, a single "canonical" outer CU is chosen to expand.
> However, when an inline function is found, all such CUs are expanded.
> 
> A change was also needed to the index writer to handle this case.
> There, entries coming from a PU should note the correct including CU.
> This must be done because, with .debug_names or .gdb_index, gdb does
> not have information about unit imports.  Handling inline functions
> here means writing out a separate entry for each outermost CU that
> includes the function's PU.
> 
> I did consider changing the cooked indexer to create an internal table
> more similar to what would be created by the .debug_names (e.g.)
> reader: that is, multiple entries for each inline function.  However,
> this seemed more expensive at read time, and a main goal of the cooked
> indexer is to be fast.

The description make sense to me.  I think the dwz-ing of the DWARF
should be seen as an internal implementation detail to factor common
things, but from the "outside", it's the real CUs/TUs that count.
Semantically, we must do "as-if" there was no factoring out.

Simon