python command returns different values in a script and interactively

I’m trying to write a python script that will launch a simulator to run the current target. In my script, I’ve got this code:

foo =

print foo

print type(foo)

When I run it, I get this:


<type ‘NoneType’>

But if I run the same commands interactively, I get the right values:

(lldb) script foo =

(lldb) script print foo


(lldb) script print type(foo)

<type ‘str’>

After calling interactively, my script starts to work.

Why doesn’t it work in the script if I don’t call it interactively? How can I get it to work?



The lldb.{target,process,thread} globals are only set when running the interactive script interpreter in the lldb "script" command. They aren't available in other environments like the breakpoint commands, or Python based user defined commands, etc. They are really just for convenience when prototyping scripts.

In some actual Python code you should have some clear way, depending on the environment, what target you mean. For instance, if you are writing a Python based lldb command, you might want to operate on the currently selected target (which you can look up in the debugger passed in to you) or you might want to look up a target by name, etc. In a breakpoint command the relevant target will be the one which owns the process that owns the frame that actually hit the breakpoint, etc...


That fixed it, thanks Jim!

My next problem - I want to set a breakpoint at main and continue. This works, but I don't get the lldb prompt back, and can't do debugging. My code is:

def start (debugger, register, result, dict):
    run (debugger, register, result, dict)
    target = debugger.GetSelectedTarget()
    process = target.GetProcess()

ctrl-c doesn't break. I have to hit ctrl-z and kill lldb.


Your debugger is in synchronous mode which means process.Continue() won't return until your process stops. If you just want to run your target and not wait for it to stop try:


then do your process.Continue()

This should let your script exit and then catch the event back in the debugger when it does stop. Then CTRL+C should work as well.

NOTE: process.Continue() won't work unless your process is already launched. Just wanted to make sure you weren't expecting it to launch your process.


It's hitting the breakpoint:

Process 1 stopped
* thread #1: tid = 0x0001, 0x00004130 factorial`main(argc=1, argv=0x0000b100) + 28 at factorial.c:32, stop reason = breakpoint 1.1
    frame #0: 0x00004130 factorial`main(argc=1, argv=0x0000b100) + 28 at factorial.c:32
   29 }
   30 */
-> 32 base = 10;
   34 printf("Factorial of %d is %d\n", base, factorial(base));
   35 return 0;

But I don't get the prompt. If I do debugger.SetAsync(False), it hits the breakpoint and gives me the prompt, but I don't get the source list that I expect when I hit a breakpoint.

The process is launched - it's running on a simulator that I'm talking to using gdb-remote.


That's to be expected. After all, SBProcess.Continue() is a scripting function that continues the process, you wouldn't want that to print stop information to stdout, that isn't an appropriate thing for a lower level function to do.

You can use SBThread::GetStatus to print the stop status of the thread in the same way the command interpreter does when it stops at a thread, if that is what you want your command to do. If you are writing a Python based command, the correct way to do this is to set the status into the result object of your command.


Also, if you are writing a command, don't forget to restore the old async status on the way out of your command.


What I'm trying to do is write a function that launches a simulator, connects to it using gdb-remote, sets a breakpoint at main, and continue so it stops at main. I've got the simulator launch down, and I can do the breakpoint/continue interactively, but when doing the breakpoint/continue in the script I get the issues I've described.

How do I set the status into my command's result object? I tried this:
    target = debugger.GetSelectedTarget()
    process = target.GetProcess()
    thread = process.GetSelectedThread()
    result = thread.GetStatus()

But it hangs.