[Lldb-commits] [PATCH] For expression evaluation, a new ThreadPlanCallFunctionGDB for executing a function call on target via register manipulation.

jingham at apple.com jingham at apple.com
Fri Jul 25 15:49:11 PDT 2014


I haven't looked over this patch in detail yet, but it would be much easier to read what you are doing if you would make your ThreadPlanCallFunctionGDB class derive from ThreadPlanCallFunction and only implement the bits that are actually different.  You will have to do this anyway before you could submit this, because this is code that gets worked on not infrequently and I don't want to maintain two identical copies of routines.

Also, as much as I love gdb I don't think ThreadPlanCallFunctionGDB is very descriptive.  It would be better to call it ThreadPlanCallFunctionNoJIT, or "UsingABI" or something like that  which says what it does without your having to know how gdb implements function calling.

If your expression only calls one function then to JIT or not to JIT is pretty much a wash.  The JIT will be more accurate since it really has to know the ABI - the debugger's just kinda guessing...  But as soon as you start calling a couple of functions not having to context switch back and forth between the debugger and the target for each function call really starts to make a difference.  The JIT quickly becomes much faster.  So I agree this should probably only be used for targets that can't JIT for one reason or another.

Also, it should be optional to implement any more than the current level of knowledge of the ABI, since for platforms that can JIT you are rewriting some fairly complex logic that the compiler already knows.  So for instance, I would hope that for x86_64, the ThreadPlanCallFunctionGDB would not work for complex functions, because it would be a waste of time to make it work...

Along these same lines, I've had a long-standing request with the llvm/clang folks for an interface like "given a function prototype, return a set of DWARF expressions for the location of the arguments, and for the return value."  The compiler obviously knows this information, but apparently there are layering problems that make it hard to for clang to tell us.  There's been some work to make this more possible recently, though nothing we can use yet.  It's just interesting to keep this in mind, because then we can make a version of PrepareTrivialCall that is more accurate and capable without having to code these details of the ABI by hand in lldb.  At that point, I would remove the injunction of the previous PP...

Jim



> On Jul 25, 2014, at 10:04 AM, Deepak Panickal <deepak2427 at gmail.com> wrote:
> 
> Hi,
> 
> We wanted to be able to call functions while debugging for Hexagon however this is only possible from lldb currently when there is JIT support.
> Currently LLDB supports emulation via IR interpreting and executing on target via JIT however The IR interpretation is limited and cannot currently make function calls.
> 
> We have extended the IR interpreter so that it can execute a function call on target, via register manipulation. This is the same method
> that is used by GDB for calling a function. This involved handling the Call IR instruction, passing arguments to a new thread plan and collecting any return values and
> passing them back into the IR interpreter.
> 
> Several interfaces to the ABI were extended to allow more detailed information about arguments and return values when setting up a trivial call. See "ABI::PrepareTrivialCall".
> 
> Currently the expression evaluator checks if an expression can be interpreted and if it can it uses the IR interpreter, if it can't then it tries to JIT the expression and
> run it on target. It seems however that for targets that can JIT, it would be better to use that when executing a function call since its presumably much more robust.
> Perhaps this should be used exclusively for targets that cannot JIT?
> 
> http://reviews.llvm.org/D4672
> 
> Files:
>  include/lldb/Expression/IRInterpreter.h
>  include/lldb/Expression/IRMemoryMap.h
>  include/lldb/Target/ThreadPlanCallFunctionGDB.h
>  source/Expression/ClangUserExpression.cpp
>  source/Expression/IRInterpreter.cpp
>  source/Expression/IRMemoryMap.cpp
>  source/Target/CMakeLists.txt
>  source/Target/ThreadPlanCallFunction.cpp
>  source/Target/ThreadPlanCallFunctionGDB.cpp
> <D4672.11884.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits




More information about the lldb-commits mailing list