This is an archive of the discontinued LLVM Phabricator instance.

Fix bug with function resolution when using IR Interpreter
ClosedPublic

Authored by ted on Feb 29 2016, 5:17 PM.

Details

Summary

Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process.

Diff Detail

Event Timeline

ted updated this revision to Diff 49436.Feb 29 2016, 5:17 PM
ted retitled this revision from to Fix bug with function resolution when using IR Interpreter.
ted updated this object.
ted added a reviewer: spyffe.
ted added a subscriber: lldb-commits.
spyffe accepted this revision.Feb 29 2016, 5:49 PM
spyffe edited edge metadata.

Aside from one minor object ownership issue this is good to go. Change the IRExecutionUnitSP to an IRExecutionUnit& and you have my blessing!

source/Expression/IRInterpreter.cpp
106

As noted below, this can just be an IRExecutionUnit&.

689

Given that the caller of Interpret has an execution_unit_sp, and Interpret does not create any objects that live longer than the Interpret invocation (specifically, the InterpreterStackFrame is stack-allocated) I believe we should not need to take the shared pointer. An IRExecutionUnit& should suffice.

This revision is now accepted and ready to land.Feb 29 2016, 5:49 PM
ted updated this revision to Diff 49542.Mar 1 2016, 1:46 PM
ted edited edge metadata.

Updated to address Sean's comments

ted closed this revision.Mar 1 2016, 1:58 PM