summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter/ScriptInterpreterPython.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add Initialize/Terminate method to Platform base pluginTamas Berghammer2015-02-121-0/+12
| | | | | | | | | | | | | Platform holds a smart pointer to each platform object created in a static variable what cause the platform destructors called only on program exit when other static variables are not availables. With this change the destructors are called on lldb_private::Terminate() + Fix DebuggerRefCount handling in ScriptInterpreterPython Differential Revision: http://reviews.llvm.org/D7590 llvm-svn: 228944
* Change void* name_token to const void* to address warnings.Bruce Mitchener2015-02-031-5/+5
| | | | | | | | | | | | Reviewers: granata.enrico, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7337 llvm-svn: 227952
* Allow python command interpreter commands to be interruptable via CTRL+C.Greg Clayton2015-01-271-19/+30
| | | | | | <rdar://problem/17935601> llvm-svn: 227163
* Respect the fact that the result object claims it doesn't want to be ↵Greg Clayton2015-01-101-12/+17
| | | | | | | | | | interactive by not forwarding STDIN to the python invocation when it isn't desired. This fixes an issue of running "script" commands via SBDebugger::HandleCommand(...) and SBCommandInterpreter::HandleCommand(...) deadlocking Xcode. <rdar://problem/18075038> llvm-svn: 225567
* Enhance the Pipe interface for better portability.Zachary Turner2014-12-171-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes a number of improvements to the Pipe interface. 1) An interface (PipeBase) is provided which exposes pure virtual methods for any implementation of Pipe to override. While not strictly necessary, this helps catch errors where the interfaces are out of sync. 2) All methods return lldb_private::Error instead of returning bool or void. This allows richer error information to be propagated up to LLDB. 3) A new ReadWithTimeout() method is exposed in the base class and implemented on Windows. 4) Support for both named and anonymous pipes is exposed through the base interface and implemented on Windows. For creating a new pipe, both named and anonymous pipes are supported, and for opening an existing pipe, only named pipes are supported. New methods described in points #3 and #4 are stubbed out on posix, but fully implemented on Windows. These should be implemented by someone on the linux / mac / bsd side. Reviewed by: Greg Clayton, Oleksiy Vyalov Differential Revision: http://reviews.llvm.org/D6686 llvm-svn: 224442
* Enable Python summaries to use custom SBTypeSummaryOptions if the user is so ↵Enrico Granata2014-11-221-0/+4
| | | | | | inclined. Updates to the webdoc will follow llvm-svn: 222593
* Complete rewrite of interactive editing support for single- and multi-line ↵Kate Stone2014-11-171-1/+1
| | | | | | | | | | | | | | | | | | | input. Improvements include: * Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only * Fallback for ASCII editing path * Support for a "faint" prompt clearly distinguished from input * Breaking lines and insert new lines in the middle of a batch by simply pressing return * Joining lines with forward and backward character deletion * Detection of paste to suppress automatic formatting and statement completion tests * Correctly reformatting when lines grow or shrink to occupy different numbers of rows * Saving multi-line history, and correctly preserving the "tip" of history during editing * Displaying visible ^C and ^D indications when interrupting input or sending EOF * Fledgling VI support for multi-line editing * General correctness and reliability improvements llvm-svn: 222163
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+35
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* Fix deadlock in Python one-line execution.Zachary Turner2014-10-081-0/+15
| | | | | | | | | | | | | | | | | Python one-line execution was using ConnectionFileDescriptor to do a non-blocking read against a pipe. This won't work on Windows, as CFD is implemented using select(), and select() only works with sockets on Windows. The solution is to use ConnectionGenericFile on Windows, which uses the native API to do overlapped I/O on the pipe. This in turn requires re-implementing Host::Pipe on Windows using native OS handles instead of the more portable _pipe CRT api. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5679 llvm-svn: 219339
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-0/+39
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Move ConnectionFileDescriptor to platform-specific Host directory.Zachary Turner2014-10-061-1/+1
| | | | | | | | | | | | As part of getting ConnectionFileDescriptor working on Windows, there is going to be alot of platform specific work to be done. As a result, the implementation is moving into Host. This patch performs the code move and fixes up call-sites appropriately. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5548 llvm-svn: 219143
* Allow Python commands to optionally take an SBExecutionContext argument in ↵Enrico Granata2014-10-011-2/+5
| | | | | | case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow llvm-svn: 218834
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-1/+89
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Allow "breakpoint command add" to add commands to more than one breakpoint ↵Jim Ingham2014-08-291-19/+23
| | | | | | | | at a time. <rdar://problem/13314462> llvm-svn: 216747
* Move Host::GetLLDBPath to HostInfo.Zachary Turner2014-08-211-4/+4
| | | | | | | | This continues the effort to get Host code moved over to HostInfo, and removes many more instances of preprocessor defines along the way. llvm-svn: 216195
* Don't enable STDIN for cases where we are supplying lines to be run in the ↵Greg Clayton2014-08-141-2/+2
| | | | | | | | embedded python interpreter. <rdar://problem/17949057> llvm-svn: 215608
* Fix some python shutdown / ordering issues.Zachary Turner2014-08-081-1/+5
| | | | | | | | Differential Revision: http://reviews.llvm.org/D4826 Reviewed by: Enrico Granata llvm-svn: 215256
* ScriptInterpreterPython: %p should be used with void-pointerDavid Majnemer2014-07-221-1/+1
| | | | | | | | | printf's %p format specifier expects an argument of type void-pointer, not type PyThreadState*. Fix this with a static_cast. Differential Revision: http://reviews.llvm.org/D4632 llvm-svn: 213695
* Test commit. Having trouble committing from one machine but notZachary Turner2014-07-181-1/+1
| | | | | | another, attempting to fix it. llvm-svn: 213413
* Fix a bug with order of operations.Zachary Turner2014-07-181-1/+1
| | | | llvm-svn: 213411
* Any commands that are executed through the public interface using ↵Greg Clayton2014-07-151-2/+2
| | | | | | | | | | | | | | SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode. Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source". Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual. This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually. <rdar://problem/17386271> llvm-svn: 213023
* Get the python scripting interface working on Windows.Zachary Turner2014-07-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a number of issues with embedded Python on Windows. In particular: 1) The script that builds the python modules was normalizing the case of python filenames during copies. The module name is the filename, and is case-sensitive, so this was breaking code. 2) Changes the build to not attempt to link against python27.lib (e.g. the release library) when linking against msvcrt debug library. Doing a debug build of LLDB with embedded python support now requires you to provide your own self-compiled debug version of python. 3) Don't import termios when initializing the interpreter. This is part of a larger effort to remove the dependency on termios since it is not available on Windows. This particular instance was unnecessary and unused. Reviewed by: Todd Fiala Differential Revision: http://reviews.llvm.org/D4441 llvm-svn: 212785
* Add host layer support for pipes.Greg Clayton2014-07-021-12/+8
| | | | | | | | | | | Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use. Windows benefits include: - Being able to interrupt running processes when IO is directly hooked up - being able to interrupt long running python scripts - being able to interrupt anything based on ConnectionFileDescriptor llvm-svn: 212220
* This creates a valid Python API for Windows, pending some issues. The ↵Deepak Panickal2014-07-011-0/+5
| | | | | | | | | | | | | changes included are - - Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms - Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll - More build fixes for Windows The pending issues are that two Python modules, termios and pexpect are not available on Windows. These are currently required for the Python command interpreter to be used from within LLDB. llvm-svn: 212111
* Interpreter: kill some dead codeSaleem Abdulrasool2014-06-131-4/+1
| | | | | | | Remove commented out code and an unnecessary associated scope. No functional change. llvm-svn: 210882
* Remove unused variablesSaleem Abdulrasool2014-06-131-3/+0
| | | | | | | | Address the 'variable set but not used' warning from GCC. In some cases a few additional calls were removed where there should be no visible side effects of the calls (i.e. should not effect any cached state). llvm-svn: 210879
* lldb TOT is dropping the last entry for multi-line IOHandlers that use the ↵Greg Clayton2014-05-081-1/+1
| | | | | | | | IOHandlerDelegateMultiline. <rdar://problem/16844164> llvm-svn: 208336
* "DONE" is being left in multi-line results when it shouldn't for non ↵Greg Clayton2014-05-021-1/+1
| | | | | | | | terminal input. <rdar://problem/16790579> llvm-svn: 207818
* Fixed CTRL+C related issues:Greg Clayton2014-05-021-11/+26
| | | | | | | | | | | | - CTRL+C wasn't clearing the command in lldb - CTRL+C doesn't work in python macros in lldb - Ctrl+C no longer interrupts the running process that you attach to <rdar://problem/15949205> <rdar://problem/16778652> <rdar://problem/16774411> llvm-svn: 207816
* Free the strong reference to a lldb::SBDebugger that the script interpreter ↵Greg Clayton2014-04-251-0/+11
| | | | | | was holding onto in the "lldb.debugger" global variable. llvm-svn: 207292
* Switch NULL to C++11 nullptr in source/InterpreterEd Maste2014-04-201-75/+75
| | | | | | Patch by Robert Matusewicz llvm-svn: 206711
* Add the ability to set python breakpoint commands from the SBBreakpoint & ↵Jim Ingham2014-04-021-32/+54
| | | | | | | | | | | SBBreakpointLocation API's. You can either provide the function name, or function body text. Also propagate the compilation error up from where it is checked so we can report compilation errors. <rdar://problem/9898371> llvm-svn: 205380
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-7/+0
| | | | | | | | | | | | | This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
* Fixed the command line LLDB so that "CTRL+C" will interrupt a running ↵Greg Clayton2014-02-241-1/+7
| | | | | | process again. llvm-svn: 202086
* Don't crash when we build with python enabled, yet we don't link in the ↵Greg Clayton2014-02-211-2/+2
| | | | | | | | lldb::SB* API layer. Previously the lldb-platform and lldb-gdbserver would crash. llvm-svn: 201872
* <rdar://problem/15906684>Enrico Granata2014-02-191-5/+1
| | | | | | | | The way in which we were determining whether a python module had already been imported in the current session stopped working due to the IOHandler changes As a result, importing in a new debug session a module which had been imported in a previous session did not work This commit restores that functionality by checking for the module's presence in the session dictionary (which should be more correct anyway) llvm-svn: 201623
* Fixed deadlocks that could occur when using python for breakpoints, ↵Greg Clayton2014-02-131-38/+48
| | | | | | | | | operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
* <rdar://problem/15936507>Enrico Granata2014-02-051-7/+5
| | | | | | | | ScriptInterpreterPython caches the lldb.embedded_interpreter module, and since it caches it in a refcounting-safe PythonObject, the refcount will appropriately go down 1 every time a ScriptInterpreterPython is deallocated However, we were only importing the module once - in InitializePrivate(). In a handful of interpreter creations, the refcount on the run_one_line function would end up at 0, causing LLDB to crash This fixes it by also importing the module for every interpreter, which ensures correct refcounting llvm-svn: 200816
* Fixed b18655: cleaned up script interpreter file reference handling.Todd Fiala2014-01-301-5/+22
| | | | | | | | | | | | | | This change addresses shutdown crashes in the python lldb module when the script interpreter was hanging on to saved file references after leaving a session. It also gets rid of extra references to the stdin/stdout/stderr python file objects that are created when entering the session. This change also moves the bundled pyexpect 2.4 library to the front of the python library path so that a python distribution default pyexpect (2.3 in Ubuntu 12.04) is not picked up first. llvm-svn: 200486
* "script help (lldb.SBThread)" output stops before all output is displayed. ↵Greg Clayton2014-01-301-7/+9
| | | | | | | | Fixed now. <rdar://problem/15942977> llvm-svn: 200476
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-1041/+479
| | | | | | | | | | | | 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
* Fixed internal code to not link against and code from "lldb/API/*". Greg Clayton2013-12-021-2/+1
| | | | | | | | | | lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used. Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number. Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings. llvm-svn: 196141
* Change lldb from building against a Python framework out ofJason Molenda2013-11-231-4/+0
| | | | | | | | | the installed SDK to using the current OS installed headers/libraries. This change is to address the removal of the Python framework from the Mac OS X 10.9 (Mavericks) SDK, and is the recommended workaround via https://developer.apple.com/library/mac/technotes/tn2328/_index.html llvm-svn: 195557
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-4/+4
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-4/+4
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Fix the format warnings.Sylvestre Ledru2013-10-311-4/+4
| | | | | | | | | | In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64. Fixes bug #17551. Patch by "/dev/humancontroller" llvm-svn: 193832
* Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to ↵Greg Clayton2013-10-171-119/+41
| | | | | | link. llvm-svn: 192857
* <rdar://problem/14972424>Greg Clayton2013-10-151-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the registers on the remote server. When those packets aren't supported, LLDB doesn't know what the registers look like. This checkin implements a setting that can be used to specify a python file that contains the registers definitions. The setting is: (lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py Inside module there should be a function: def get_dynamic_setting(target, setting_name): This dynamic setting function is handed the "target" which is a SBTarget, and the "setting_name", which is the name of the dynamic setting to retrieve. For the GDB remote target definition the setting name is 'gdb-server-target-definition'. The return value is a dictionary that follows the same format as the OperatingSystem plugins follow. I have checked in an example file that implements the x86_64 GDB register set for people to see: examples/python/x86_64_target_definition.py This allows LLDB to debug to any archticture that is support and allows users to define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo) are not supported by the remote GDB server. A few benefits of doing this in Python: 1 - The dynamic register context was already supported in the OperatingSystem plug-in 2 - Register contexts can use all of the LLDB enumerations and definitions for things like lldb::Format, lldb::Encoding, generic register numbers, invalid registers numbers, etc. 3 - The code that generates the register context can use the program to calculate the register context contents (like offsets, register numbers, and more) 4 - True dynamic detection could be used where variables and types could be read from the target program itself in order to determine which registers are available since the target is passed into the python function. This is designed to be used instead of XML since it is more dynamic and code flow and functions can be used to make the dictionary. llvm-svn: 192646
* Add the capability for LLDB to query an arbitrary Python module (passed in ↵Enrico Granata2013-10-141-1/+68
| | | | | | | | | | | as a file path) for target-specific settings This is implemented by means of a get_dynamic_setting(target, setting_name) function vended by the Python module, which can respond to arbitrary string names with dynamically constructed settings objects (most likely, some of those that PythonDataObjects supports) for LLDB to parse This needs to be hooked up to the debugger via some setting to allow users to specify which module will vend the information they want to supply llvm-svn: 192628
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-261-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
OpenPOWER on IntegriCloud