Depends on:
* https://github.com/llvm/llvm-project/pull/168895
Note, the last commit is the one with the actual fix. The others are
drive-by/test changes
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
0549aa11c2