[all-commits] [llvm/llvm-project] 88d3c1: [lldb][ClangExpression] Add asm() label to all Fun...

Michael137 via All-commits all-commits at lists.llvm.org
Wed Aug 17 01:03:12 PDT 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 88d3c1db453189c3c76b5b83e4d47b2c7f4adf1f
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2022-08-17 (Wed, 17 Aug 2022)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/make/Makefile.rules
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    A lldb/test/API/lang/cpp/abi_tag_lookup/Makefile
    A lldb/test/API/lang/cpp/abi_tag_lookup/TestAbiTagLookup.py
    A lldb/test/API/lang/cpp/abi_tag_lookup/main.cpp

  Log Message:
  [lldb][ClangExpression] Add asm() label to all FunctionDecls we create from DWARF

When resolving symbols during IR execution, lldb makes a last effort attempt
to resolve external symbols from object files by approximate name matching.
It currently uses `CPlusPlusNameParser` to parse the demangled function name
and arguments for the unresolved symbol and its candidates. However, this
hand-rolled C++ parser doesn’t support ABI tags which, depending on the demangler,
get demangled into `[abi:tag]`. This lack of parsing support causes lldb to never
consider a candidate mangled function name that has ABI tags.

The issue reproduces by calling an ABI-tagged template function from the
expression evaluator. This is particularly problematic with the recent
addition of ABI tags to numerous libcxx APIs.

The issue stems from the fact that `clang::CodeGen` emits function
function calls using the mangled name inferred from the `FunctionDecl`
LLDB constructs from DWARF. Debug info often lacks information for
us to construct a perfect FunctionDecl resulting in subtle mangled
name inaccuracies.

This patch side-steps the problem of inaccurate `FunctionDecl`s by
attaching an `asm()` label to each `FunctionDecl` LLDB creates from DWARF.
`clang::CodeGen` consults this label to get the mangled name as one of
the first courses of action when emitting a function call.

LLDB already does this for C++ member functions as of


* Added API tests

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

More information about the All-commits mailing list