DispatchInput is for you to give input into the debugger which will be fed to the top level InputReader.
LLDB has input readers that funnel one stdin into which ever input reader is on the top. LLDB has many input readers: - the command interpreter - the stdin for the process - the embedded python script interpreter - multi-line code expressions when you type "expression<RETURN>" - multi-line python expressions for breakpoints and such By default the command interpreter is the one and only input reader. (lldb) The input read stack looks like: 1 - command interpreter If you then type "script": (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> Now the input read stack looks like: 1 - python interactive interpreter 2 - command interpreter Any data passed into DispatchInput() will be passed to the top level interpreter until it decides it should be removed from the stack (by typing "quit()" in the python interactive interpreter). So think of DispatchInput as supplying stdin to LLDB and LLDB will route that information as needed to the correct interpreter. HandleCommand always goes to the command interpreter, no matter what input reader is being used. Greg Clayton On Jun 28, 2013, at 6:45 AM, "Langmuir, Ben" <[email protected]> wrote: > Is there documentation for DispatchInput somewhere? There are no comments in > SBDebugger.h about it, and none of the examples seem to use it. What is the > difference between DispatchInput and HandleCommand? > > Ben > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Filipe >> Cabecinhas >> Sent: Thursday, June 27, 2013 2:26 PM >> To: Langmuir, Ben >> Cc: Enrico Granata; [email protected] >> Subject: Re: [lldb-dev] run after process stop using python API >> >> Hi Ben, >> >> The problem you seem to be having is not taking into account the output of >> the debugger. >> When you send the “run” command, it pushes an InputReader (I think) and >> asks you if you're sure you want to continue. >> If you take this into account, you can print that message on your user's >> console, and the DispatchInput() with the reply. Could you try that and see >> if >> it works? >> If it doesn't work, you may find it necessary to do something like the driver >> does, where you give the debugger an stdin and stdout and use those for all >> input/output from/to the debugger itself. >> >> Your UI over lldb should always try to use the SB* API, and never >> HandleCommand (except for direct user input, but even then, DispatchInput >> or the debugger's stdin should be possible to use, so you don't need more >> than one input path). >> >> Regards, >> >> Filipe >> >> >> On Thu, Jun 27, 2013 at 5:40 AM, Langmuir, Ben <[email protected]> >> wrote: >>> Just being able to re-run the target at any (reasonable) point. I’m >>> working on a frontend for lldb using the python api, and I’m using the >>> command interpreter to deal with user input. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Ben >>> >>> >>> >>> From: Enrico Granata [mailto:[email protected]] >>> Sent: Wednesday, June 26, 2013 5:15 PM >>> To: Langmuir, Ben >>> Cc: Malea, Daniel; [email protected] >>> >>> >>> Subject: Re: [lldb-dev] run after process stop using python API >>> >>> >>> >>> $ ./lldb /bin/ls >>> >>> Current executable set to '/bin/ls' (x86_64). >>> >>> (lldb) sett set auto-confirm true >>> >>> (lldb) b malloc >>> >>> Breakpoint 1: 2 locations. >>> >>> (lldb) r >>> >>> Process 48551 launched: '/bin/ls' (x86_64) >>> >>> Process 48551 stopped >>> >>> * thread #1: tid = 0x5edda, 0x00007fff906cd8f9 >>> libsystem_malloc.dylib`malloc, stop reason = breakpoint 1.2 >>> >>> frame #0: 0x00007fff906cd8f9 libsystem_malloc.dylib`malloc >>> >>> libsystem_malloc.dylib`malloc: >>> >>> -> 0x7fff906cd8f9: pushq %rbp >>> >>> 0x7fff906cd8fa: movq %rsp, %rbp >>> >>> 0x7fff906cd8fd: pushq %rbx >>> >>> 0x7fff906cd8fe: pushq %rax >>> >>> (lldb) r >>> >>> Process 48554 launched: '/bin/ls' (x86_64) >>> >>> Process 48554 stopped >>> >>> * thread #1: tid = 0x5edf2, 0x00007fff906cd8f9 >>> libsystem_malloc.dylib`malloc, stop reason = breakpoint 1.2 >>> >>> frame #0: 0x00007fff906cd8f9 libsystem_malloc.dylib`malloc >>> >>> libsystem_malloc.dylib`malloc: >>> >>> -> 0x7fff906cd8f9: pushq %rbp >>> >>> 0x7fff906cd8fa: movq %rsp, %rbp >>> >>> 0x7fff906cd8fd: pushq %rbx >>> >>> 0x7fff906cd8fe: pushq %rax >>> >>> >>> >>> You want to set the auto-confirm lldb setting to true before you issue >>> the second run >>> >>> >>> >>> What exactly are you trying to achieve, if you can discuss it? >>> >>> >>> >>> Enrico Granata >>> 📩 egranata@.com >>> ☎️ 27683 >>> >>> >>> >>> On Jun 26, 2013, at 2:10 PM, Langmuir, Ben <[email protected]> >> wrote: >>> >>> >>> >>> How do I turn off the prompt setting? >>> >>> Also, continue isn’t what I want – I really do want to re-run the >>> program from the start. >>> >>> >>> >>> Ben >>> >>> >>> >>> From: Malea, Daniel >>> Sent: Wednesday, June 26, 2013 5:08 PM >>> To: Langmuir, Ben; [email protected] >>> Subject: Re: [lldb-dev] run after process stop using python API >>> >>> >>> >>> 'run' is a GDB alias for process launch. If a process is already >>> running, the command interpreter may be waiting for confirmation from >>> the user that it's OK to restart the process (unless you turned off >>> the prompt setting beforehand)... You probably want to issue a >>> "continue" command to restart the process. >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Dan >>> >>> >>> >>> From: <Langmuir>, Ben Langmuir <[email protected]> >>> Date: Wednesday, 26 June, 2013 4:57 PM >>> To: "[email protected]" <[email protected]> >>> Subject: [lldb-dev] run after process stop using python API >>> >>> >>> >>> I’m trying to use the ‘run’ command from the python API when my >>> process has stopped at a breakpoint, but it appears to hang. Script >> attached. >>> >>> >>> >>> i.HandleCommand('b main', res) >>> >>> i.HandleCommand('r', res) -> runs to breakpoint correctly >>> >>> i.HandleCommand('r', res) -> appears to hang >>> >>> >>> >>> This seems like a bug, but I thought I would ask in case the >>> interpreter was waiting for some kind of input I wasn’t providing… >>> I’m running on Linux, and haven’t had a chance to try OS X yet. >>> >>> >>> >>> Ben >>> >>> _______________________________________________ >>> 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 >>> > > _______________________________________________ > 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
