I was wondering if anyone could briefly explain to me the difference between synchronous and asynchronous modes, from the point of view of the command-line driver.
I presume async mode is to allow commands to be entered without halting the inferior? Like GDB's run&? But I can't seem to figure out how to enable that anywhere.
I don't believe there's a user-facing command to enable async mode explicitly -- SBDebugger::SetAsync() is available only via the API and is used in a few places by the command line driver where LLDB doesn't want to wait for a command to complete before returning to the prompt. For an example, see Driver.cpp:1596 which implements attaching to a process via "lldb -p <pid>" and allows users to issue commands while the process is still running.
That said, the async switch is still somewhat foreign to me, as I've only dealt with it in the context of a few testcases. Greg/Jim may have thought more about this subject and may have further insight.
The way the command line lldb works at present is that if you attach to a process (or run it with the stdio put to another terminal via the -tty option) then lldb runs in asynchronous mode. E.g.:
> lldb -n Calendar
Attaching to process with:
process attach -n "Calendar"
Process 211 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
Process 211 resuming
I still have a command prompt, so for instance I can check status and interrupt
(lldb) process status
Process 211 is running.
(lldb) process interrupt
Process 211 stopped
* thread #1: tid = 0x0703, function: mach_msg_trap , stop reason = signal SIGSTOP
frame #0: 0x00007fff8e531686 libsystem_kernel.dylib`mach_msg_trap
libsystem_kernel.dylib`mach_msg_trap + 10:
-> 0x7fff8e531686: ret
So we are running the command interpreter in "synchronous" mode.
But we never came up with a really good way to keep the lldb input alive when sharing a terminal with a process, so if you run as normal then you won't have access to the command prompt till an execution control command returns with the process stopped. We thought of doing something like what screen does and stealing some ^I^I or whatever to be the "debugger input" key. But that wasn't terribly appealing.
More importantly, right now you can't do all that much in lldb when the process is running. You can set breakpoints, which is useful, but that's about all. At some point we will get around to implementing always running threads and that sort of thing, at which point keeping the async mode on will be more interesting to work on.
Fantastic, thanks guys for helping clear that up.