🍒[llvm][dsymutil] Use the DW_AT_name of the uniqued DIE for insertion into .debug_names

[Michael137]

We've been seeing dsymutil verification failures like:

error: Name Index @ 0x0: Entry @ 0x11949d: mismatched Name of DIE @ 0x9c644c:
index - apply<(lambda at /some/build/dir/lib/LLVMSupport/include/llvm/Support/Error.h:1070:35)>;
debug_info - apply<(lambda at /some/build/dir/lib/LLVMCustom/include/llvm/Support/Error.h:1070:35)>
apply, _ZN11custom_llvm18ErrorHandlerTraitsIRFvRNS_13ErrorInfoBaseEEE5applyIZNS_12consumeErrorENS_5ErrorEEUlRKS1_E_EES7_OT_NSt3__110unique_ptrIS1_NSD_14default_deleteIS1_EEEE.

Not how the name of the DIE has a different lambda path than the one
that was used to insert the DIE into debug_names.

The root cause of the issue is that we have a DW_AT_subprogram
definition whose DW_AT_specification DIE got deduplicated. But the
DW_AT_name of the original specification is different than the one it
got uniqued to. That’s technically fine because dsymutil uniques by
linkage name, which uniquely identifies any function with non-internal
linkage.

But we insert the definition DIE into the debug-names table using the
DW_AT_name of the original specification (we call
getDIENames(InputDIE…)). But what we really want to do is use the name
of the adjusted DW_AT_specifcation (i.e., the DW_AT_specification of
the output DIE). That’s not as simple as it sounds because we can’t just
get ahold of the DIE in the output CU. We have to grab the ODR
DeclContext of the input DIE’s specification. That is the only link
back to the canonical specification DIE. For that to be of any use, we
have to stash the DW_AT_name into DeclContext so we can use it in
getDIENames.

We have to account for the possibility of multiple levels of
DW_AT_specification/DW_AT_abstract_origin. So my proposed solution
is to recursively scan the referenced DIE’s, grab the canonical DIE for
those and get the name from the DeclContext (if none exists then use
the DW_AT_name of the DIE itself).

One remaining question is whether we need to handle the case where a DIE
has a DW_AT_specification and a DW_AT_abstract_origin? That
complicates the way we locate DW_AT_name. We'd have to adjust
getCanonicalDIEName to handle this. But it's not clear what a
DW_AT_name would be for such cases. Worst case at the moment we take
the wrong path up the specifications and don't find any DW_AT_name,
and don't end up indexing that DIE. Something to keep an eye out for.

rdar://149239553
(cherry picked from commit 0549aa1)

[Michael137]

@swift-ci test

[Michael137]

@swift-ci test macOS

[Michael137]

@swift-ci test windows

[Michael137]

@swift-ci test

[JDevlieghere]

LGTM. Reviewed by me upstream.

[Michael137]

@swift-ci test windows