summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter/ScriptInterpreterNone.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-42/+0
| | | | | | | | | | | | | | | | | | | | | | | Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-2/+3
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* <rdar://problem/12586188> Make ImportError a special case for "command ↵Enrico Granata2012-10-311-1/+1
| | | | | | | | | | | script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
* <rdar://problem/12491420>Greg Clayton2012-10-181-1/+1
| | | | | | | | | | Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
* <rdar://problem/11538779> Fixing issues where Python scripts were not able ↵Enrico Granata2012-06-071-1/+1
| | | | | | to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
* Fixed the way set/show variables were being accessed to being natively Greg Clayton2010-09-181-5/+5
| | | | | | | | | | | | | | | | | | accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects. While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in. Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only"). llvm-svn: 114252
* We can do better when reporting the status of one-liner script execution.Johnny Chen2010-07-301-2/+3
| | | | | | | | | Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool instead of void and take one additional parameter as CommandReturnObject *. Propagate the status of one-liner execution back appropriately. llvm-svn: 109899
* Very large changes that were needed in order to allow multiple connectionsGreg Clayton2010-06-231-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+38
llvm-svn: 105619
OpenPOWER on IntegriCloud