> On Jun 26, 2014, at 5:30 PM, Zachary Turner <[email protected]> wrote: > > > > > On Thu, Jun 26, 2014 at 4:47 PM, Sean Callanan <[email protected]> wrote: > Zachary, > > LLI’s interpreter is (a) not really supported code, having been superseded by > the JIT; and (b) founded on the assumption that we’re interpreting inside the > current process. > The LLDB IRInterpreter is focused on interpreting in the context of another > process (the IRMemoryMap is the interface it uses). > > It’s not clear to me what’s doing this. On OS X we don’t get this error: > > Isn't the IRInterpreter also only for interpreting inside the current > process? At least the header file implies so. > > //---------------------------------------------------------------------- > /// @class IRInterpreter IRInterpreter.h "lldb/Expression/IRInterpreter.h" > /// @brief Attempt to interpret the function's code if it does not require > /// running the target. > /// > /// In some cases, the IR for an expression can be evaluated entirely > /// in the debugger, manipulating variables but not executing any code > /// in the target. The IRInterpreter attempts to do this. > //---------------------------------------------------------------------- > > Of course LLDB itself also needs to interpret things inside the context of > the remote process, but I assumed that was handled by a different class.
You are misunderstanding what "evaluated entirely in the debugger means". If the expression involves ONLY memory/register reads/writes to the remote process, then the debugger can emulate running the expression in the target process, without having to actually let the target run. For instance, if the expression is just "local_variable = 5", we are perfectly capable of changing the value of local_variable in the target by a direct memory or register write. OTOH if an expression has a function call, we don't try to emulate all the code of the function call locally, instead we JIT the code to do so and run it in the target. But we are still always resolving all the addresses in the IR as we interpret it in the target process. There isn't any place in lldb where we do local code insertion or IR emulation to change our own state. We're not that cool... Jim > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
