[lldb-dev] Async vs. sync

[Richard Mitton]

Fantastic, thanks guys for helping clear that up.

Richard Mitton
richard at codersnotes.com

On 10/01/2013 09:54 AM, Jim Ingham wrote:
> 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.
> (lldb) c
> 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
>     0x7fff8e531687:  nop
>
> 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.
>
> Jim
>
> On Sep 30, 2013, at 12:59 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
>
>> Hi Richard,
>>
>> 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.
>>
>> In terms of user-friendliness, I think it would be better to add async variants of commands (like GDB's "run&") by supporting an optional "--async" flag in commands where it makes sense (like "process launch"), than to allow users access to the global async switch (a la GDB's "set target-async on" command) which has much further-reaching implications for the whole debugger...
>>
>> 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.
>>
>> Cheers,
>> Dan
>>
>> -----Original Message-----
>> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Richard Mitton
>> Sent: Monday, September 30, 2013 3:16 PM
>> To: lldb-dev at cs.uiuc.edu
>> Subject: [lldb-dev] Async vs. sync
>>
>> Hi,
>>
>> 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.
>>
>> --
>> Richard Mitton
>> richard at codersnotes.com
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev