Hi Ben, On Fri, Jun 28, 2013 at 1:02 PM, Langmuir, Ben <[email protected]> wrote: > Two questions: > > 1. If the default is to have an input reader for the command interpreter, can > I just call DispatchInput to run a command? That doesn't seem to work for me.
I find it weird that it doesn't, but while taking a look at the SublimeLLDB plugin*, I see that I actually used the SBDebugger's input/output file handles. Maybe I found this same problem (I did the plugin about a year ago). * The code quality is not that good, but if you find it handy, be my guest and check out how I used LLDB.framework. I'm also not sure if the code has bitrotted or not. > 2. If 'run' pushes a new InputReader, how should my python code be notified > of that? There is no event on the debugger's default listener. Ah, yes. You would expect, but there's no API for that. There is one to check if a given InputReader is the top one, which may help you, though. Otherwise, a patch would be needed for InputReader-related events. Regards, Filipe > > Ben > >> -----Original Message----- >> From: Greg Clayton [mailto:[email protected]] >> Sent: Friday, June 28, 2013 1:45 PM >> To: Langmuir, Ben >> Cc: Filipe Cabecinhas; [email protected] >> Subject: Re: [lldb-dev] run after process stop using python API >> >> 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
