为什么 LLDB 的 print（或 p）命令如此有限？答案

【问题标题】：Why is LLDB's print (or p) command so limited?为什么 LLDB 的 print（或 p）命令如此有限？
【发布时间】：2015-08-03 22:02:06
【问题描述】：

当我第一次听说它时，它听起来像是一个很棒的功能——一个 c++ REPL。但是，它不能调用 STL 函数或方法，并且还有很多其他问题。这个问题也适用于条件断点。

它仍然是一个实验性功能，还是开发人员刚刚放弃了它？

例子：

(lldb) p iterator->aField
error: call to a function 'std::__1::__wrap_iter<aClass const*>::operator->() const' ('_ZNKSt3__111__wrap_iterIPK8aClassEptEv') that is not present in the target
error: 0 errors parsing expression
error: The expression could not be prepared to run in the target

【问题讨论】：

是不是operator->函数已经被编译器内联了？
@TheParamagneticCroissant 这和什么有什么关系？
如果函数是内联的并且不存在于可执行文件中，调试器几乎没有机会调用它。
它不应该能够即时解释（至少）来自模板的代码吗？（至少最终；如果这是一个实验性功能，他们可能还没有时间这样做）
“它不应该能够即时解释（至少）来自模板的代码吗？” – 嗯……不。

标签： c++ lldb

【解决方案1】：

目前，调试器没有很好的方法来生成模板特化的方法，编译器只发出内联版本。并且调试器不能调用内联方法。

这是一个有限的技巧（尽管它需要 C++11），您可以使用它来强制编译器生成相关模板类的完整副本，以便调试器可以调用函数。例如，如果我输入：

template class std::vector<int>;

在我的源代码中，编译器将生成 std::vector 的 int 特化中所有函数的真实副本。这显然不是一个完整的解决方案，你应该只在调试版本中这样做，否则它会使你的代码膨胀。但是当你真正调用方法的类型有几种时，这是一个有用的技巧。

你提到了“一大堆其他问题”。请使用 lldb bugzilla：https://llvm.org/bugs 或 Apple 的错误报告器：http://bugreporter.apple.com，就您在 lldb 中发现的任何表达式解析器问题提交错误。表达式解析器正在积极开发中

【讨论】：