[all-commits] [llvm/llvm-project] b296dd: [lldb][DWARFASTParserClang] Attach linkage name to...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b296ddd91cb8e7676b3c38ca7f6d7bdbd84eb4af
      https://github.com/llvm/llvm-project/commit/b296ddd91cb8e7676b3c38ca7f6d7bdbd84eb4af
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2023-02-10 (Fri, 10 Feb 2023)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    A lldb/test/API/lang/cpp/external_ctor_dtor_lookup/Makefile
    A lldb/test/API/lang/cpp/external_ctor_dtor_lookup/TestExternalCtorDtorLookup.py
    A lldb/test/API/lang/cpp/external_ctor_dtor_lookup/lib.h
    A lldb/test/API/lang/cpp/external_ctor_dtor_lookup/main.cpp

  Log Message:
  -----------
  [lldb][DWARFASTParserClang] Attach linkage name to ctors/dtors if missing

**Summary**

This patch addresses the case where we have a `DW_AT_external`
subprogram for a constructor (and/or destructor) that doesn't carry
a `DW_AT_linkage_name` attribute. The corresponding DIE(s) that
represent the definition will have a linkage name, but if the name
contains constructs that LLDBs fallback mechanism for guessing mangled
names to resolve external symbols doesn't support (e.g., abi-tags)
then we end up failing to resolve the function call.

We address this by trying to find the linkage name before we create
the constructor/destructor decl, which will get attached using
an `AsmLabelAttr` to make symbol resolution easier.

**Testing**

* Added API test

Differential Revision: https://reviews.llvm.org/D143652