[all-commits] [llvm/llvm-project] 958608: [lldb] Allow LLDB to automatically retry a failed ...

Raphael Isemann via All-commits all-commits at lists.llvm.org
Thu Dec 10 03:29:53 PST 2020


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 958608285eb4d04c6e3dc7071fa429b43597585b
      https://github.com/llvm/llvm-project/commit/958608285eb4d04c6e3dc7071fa429b43597585b
  Author: Raphael Isemann <teemperor at gmail.com>
  Date:   2020-12-10 (Thu, 10 Dec 2020)

  Changed paths:
    M lldb/include/lldb/Target/Target.h
    M lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
    M lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
    M lldb/source/Target/Target.cpp
    M lldb/source/Target/TargetProperties.td
    A lldb/test/API/commands/expression/import-std-module/retry-with-std-module/Makefile
    A lldb/test/API/commands/expression/import-std-module/retry-with-std-module/TestRetryWithStdModule.py
    A lldb/test/API/commands/expression/import-std-module/retry-with-std-module/main.cpp

  Log Message:
  -----------
  [lldb] Allow LLDB to automatically retry a failed expression with an imported std C++ module

By now LLDB can import the 'std' C++ module to improve expression evaluation,
but there are still a few problems to solve before we can do this by default.
One is that importing the C++ module is slightly slower than normal expression
evaluation (mostly because the disk access and loading the initial lookup data
is quite slow in comparison to the barebone Clang setup the rest of the LLDB
expression evaluator is usually doing). Another problem is that some complicated
types in the standard library aren't fully supported yet by the ASTImporter, so
we end up types that fail to import (which usually appears to the user as if the
type is empty or there is just no result variable).

To still allow people to adopt this mode in their daily debugging, this patch
adds a setting that allows LLDB to automatically retry failed expression with a
loaded C++ module. All success expressions will behave exactly as they would do
before this patch. Failed expressions get a another parse attempt if we find a
usable C++ module in the current execution context. This way we shouldn't have
any performance/parsing regressions in normal debugging workflows, while the
debugging workflows involving STL containers benefit from the C++ module type
info.

This setting is off by default for now with the intention to enable it by
default on macOS soon-ish.

The implementation is mostly just extracting the existing parse logic into its
own function and then calling the parse function again if the first evaluation
failed and we have a C++ module to retry the parsing with.

Reviewed By: shafik, JDevlieghere, aprantl

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




More information about the All-commits mailing list