That is not the intention of the design, and also not what I see:
(lldb) source list -f foo.c -l 1
1 #include <stdio.h>
2
3 int
4 foo (int input)
5 {
6 int local_var = input * 5;
7 printf ("Local var: %d.\n", local_var);
8 return local_var;
9 }
10
11 int
(lldb)
12 main (int argc, char **argv)
13 {
14 int local_var = argc;
15 printf ("Foo returns: %d.\n", foo (local_var));
16 return 1;
17 }
(lldb) b s -p "return local_var"
Breakpoint 1: where = foo`foo + 41 at foo.c:8, address = 0x0000000100000ef9
(lldb) run
Process 98518 launched: '/private/tmp/foo' (x86_64)
Local var: 5.
Process 98518 stopped
* thread #1: tid = 0x3663ec, function: foo , stop reason = breakpoint 1.1
frame #0: 0x0000000100000ef9 foo`foo at foo.c:8
5 {
6 int local_var = input * 5;
7 printf ("Local var: %d.\n", local_var);
-> 8 return local_var;
9 }
10
11 int
So I am in foo, there is a "local_var" in frame 0, where its value is 5, and in
frame 1 where its value is 1. So I do:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> frame_0 = lldb.thread.GetFrameAtIndex(0)
>>> print frame_0.EvaluateExpression("local_var")
(int) $0 = 5
>>> frame_1 = lldb.thread.GetFrameAtIndex(1)
>>> print frame_1.EvaluateExpression("local_var")
(int) $1 = 1
>>> quit()
SBFrame::EvaluateExpression, at least in this example, works on the SBFrame
that you call it on.
Note, here I am using lldb.thread, which is INDEED the command interpreter's
currently selected thread. I just did that to shorten the example. If you
wanted to get the process/thread/frame independent of entities selected in the
Command Interpreter, then you should use the accessors on SBDebugger, SBTarget,
SBProcess and SBThread. The Python docs explicitly state that you should NOT
use lldb.process/lldb.thread or lldb.frame anywhere but in the interactive
script interpreter. They aren't even guaranteed to be set in other contexts.
Anyway, if you have some example (not using
lldb.process/lldb.thread/lldb.frame) where the EvaluateExpression on a SBFrame
object is evaluating the expression is the context of some other frame, please
file a bug and we will take a look.
Jim
On Jun 10, 2013, at 1:46 PM, Andrey Zaytsev <[email protected]>
wrote:
> Hello everyone.
>
> I just realised thing which leads to crash of debuggee in some cases. We had
> a bug in our tracker: http://youtrack.jetbrains.com/issue/OC-7389
>
> We have some system of value renderers. Each renderer(e.g for NSCollections)
> evaluates some stuff to get info about collection elements. So does a number
> of Summary and Synthetic Providers too.
>
> In SB-API it is implemented with EvaluateExpression function. One of the ways
> we can evaluate expression is to call lldb::SBFrame::EvaluateExpression()
> member function. Actually it performs execution on selected thread/frame. But
> not on the frame we call EvaluateExpression function on. It's very not
> obvious and in my opinion buggy. Usage of API in this way leads to crashes of
> debuggee process like in the ticket above. So crashes not only attempt to
> evaluate expression but attempt to get local variables with dynamic types if
> it executes target as well.
>
> So workaround for us was to select specified thread/frame before doing
> evaluation. So does interpreter's expr command.
>
>
> --
> Andrey Zaytsev
> Software Developer
> JetBrains, Inc
> http://www.jetbrains.com/
> "Develop with pleasure!"
>
> _______________________________________________
> 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
