Re: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs

[Keith Seitz <keiths@redhat.com>]

On 10/18/19 8:07 AM, Simon Marchi wrote:
>> I spent a little time trying to figure out what CU is used for in
>> dwarf2_physname() and its callees.  What I noticed most is that
>> cu->language is used to figure out some appropriate thing to do.
>> I seem to remember Keith running into problems with mismatched
>> languages in different CUs.  So there might be problems if the
>> languages associated with the CUs are different.
> 
> Yeah, I remember this saga, but I did not really follow it.  Keith, would
> you have an idea of what would be the right CU to pass here?

The language mismatch that Kevin refers to was a problem that appeared
with LTO. The primary DIE would be marked artificial and having language C99.
That DIE would then import other DIEs of different languages (mostly C++),
and that would cause problems because all these symbols are supposed to
live in the same dictionary. That was resolved by moving to multidictionary
a while back. [Reminder, a symbol's language is used for searching. Different
languages now have different searching algorithms. This was introduced to
help with Pedro's multi-breakpoint/linespec work to deal with namespaces,
ABI tags, etc.]

As far as the correct DIEs to use when passing to dwarf2_physname, I don't
think/remember it being anything particularly unexpected. If the physname
for a DIE is computed, the DIE/CU passed must be able to give us this
information.

Since dwarf2_physname largely uses linkage names nowadays (there was only
one or two instances where we actually needed to compute the physname),
the correct CU/DIE would be the pair containing DW_AT_linkage_name for
the symbol.

It is debatable whether we even still need delayed physnames. I don't
think we actually need to compute physnames much anymore. [As I recall,
one place we've had to do this with was dtors. GCC did not emit linkage
names for them.]

Keith