3 ms·
Generally, failing to parse expressions at the level of abstraction of the source code being debugged: I find it fails on user defined operators, can't resolve
by cottonseed 13y ago
Generally, failing to parse expressions at the level of abstraction of the source code being debugged: I find it fails on user defined operators, can't resolve overloaded functions, etc.
Even being able to reliably evaluate C++ expressions is far from what I want: I want to be able to execute arbitrary C++ statements (including loops), use templated objects that weren't instantiated at compile time, etc. I feel like this might be close to possible using, say, the LLVM JIT, although I haven't seen anything that implies anyone is trying to build it.
edit: for example (stock gcc/gdb on Ubuntu 12.04):
#include <iostream>
int main() { std::cout << "foo\n"; }
in gdb, break at main:
(gdb) p std::cout << "foo\n"
Cannot resolve function operator<< to any overloaded instance
edit edit: lldb doesn't fare much better (OSX 10.9):
(lldb) p std::cout << "foo\n"
error: no member named 'cout' in namespace 'std'
error: 1 errors parsing expression
- emaste 13y agoLLDB does JIT your expression via Clang, and then either interprets it locally or executes it in the target, and you can execute arbitrary commands - for example: (lldb) expr for (int i=1; i<5; i++) { printf("%d\n", i * i); } 1 4 9 16 It does still fail if the appropriate constructors, templated object instantiations, etc. aren't in the target, as you point out.
- cottonseed 13y agoOh, very nice. That's clearly the right architecture. It still fails on a lot of things for me (including your above example and the std::cout example, although variants work), which I'm guessing (hoping?) is just a lack of maturity. Looking forward to see how it progresses.