summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python
Commit message (Collapse)AuthorAgeFilesLines
* Expose the ability to retrieve the result of a type validator via the SB ↵Enrico Granata2014-09-061-0/+3
| | | | | | API. To keep it simple, do not expose the pair, but just return a NULL string for success, and a non-NULL string for error; If we were to decide to expose the pair, we would need an SBTypeValidatorResult, which is fine, but it should come as part of exposing type validators through the SB API rather than as a one-off thing. So, KISS for now llvm-svn: 217299
* Expose ThreadCollection in SB APIKuba Brecka2014-09-063-0/+42
| | | | | | | | | Reviewed at http://reviews.llvm.org/D5218 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012828.html llvm-svn: 217296
* Make it clear that the load_addr property on SBAddress relies on lldb.target, Jim Ingham2014-08-271-1/+1
| | | | | | and so can only be used in the script interpreter. llvm-svn: 216625
* Fix some typos:Sylvestre Ledru2014-08-111-1/+1
| | | | | | | | * transfered => transferred * unkown => unknown * sucessfully => successfully llvm-svn: 215367
* Add an option to suppress the persistent result variable when running ↵Jim Ingham2014-08-081-0/+9
| | | | | | | | | | | | EvaluateExpression from Python. If you don't need to refer to the result in another expression, there's no need to bloat the persistent variable table with them since you already have the result SBValue to work with. <rdar://problem/17963645> llvm-svn: 215244
* Make the swig generation script use the correct python executable.Zachary Turner2014-08-021-1/+2
| | | | | | | | | | | | It was hardcoding the value "python", which will end up at best getting a different python executable (if the user has overridden the value of PYTHON_EXECUTABLE), and at worst encountering an error (if there is no copy of python on the system path). This patch changes the script to use sys.executable so that it runs the sub-script with the same executable that it was run with. llvm-svn: 214618
* (no commit message)Greg Clayton2014-07-301-0/+6
| | | | llvm-svn: 214319
* Create an _d suffixed symlink when doing a debug Windows build.Zachary Turner2014-07-171-1/+8
| | | | | | | | | | | _lldb is built as an extension module on Windows. Normally to load an extension module named 'foo', Python would look for the file 'foo.pyd'. However, when a debug interpreter is used, Python will look for the file 'foo_d.pyd'. This change checks the build configuration and creates the correct symlink name based on the build configuration. llvm-svn: 213306
* Enable the ability to enable debug info generation when evaluating expressions.Greg Clayton2014-07-111-1/+8
| | | | llvm-svn: 212792
* Get the python scripting interface working on Windows.Zachary Turner2014-07-101-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 better logging to the new Python-based SWIG generation scripts.Zachary Turner2014-07-101-10/+30
| | | | llvm-svn: 212759
* Fix typos.Bruce Mitchener2014-07-014-8/+8
| | | | llvm-svn: 212132
* This creates a valid Python API for Windows, pending some issues. The ↵Deepak Panickal2014-07-014-3/+1409
| | | | | | | | | | | | | 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
* Fix a few typos.Bruce Mitchener2014-06-271-1/+1
| | | | llvm-svn: 211851
* Fix an incomplete null structure spec in Python readline suppression module.Todd Fiala2014-06-261-1/+1
| | | | | | | | Now that I'm building Linux with clang, I'm seeing more clang warnings. This fills in some extra fields missing in the final end-of-structure-array marker. llvm-svn: 211812
* Added an option to turn OFF the "detach on error" behavior that was addedJim Ingham2014-06-251-0/+6
| | | | | | | | to debugserver when launching processes. <rdar://problem/16216199> llvm-svn: 211658
* Add SBUnixSignals.iEd Maste2014-06-231-0/+74
| | | | | | From the patch posted by Russell Harmon. llvm-svn: 211534
* Add API control of the signal disposition.Todd Fiala2014-06-232-2/+7
| | | | | | | | | | | | See http://reviews.llvm.org/D4221 for details. This commit allows you to control the signals that lldb will suppress, stop or forward using the Python and C++ APIs. Change by Russell Harmon. Xcode build system changes (and any mistakes) by Todd Fiala. Tested on MacOSX 10.9.3 and Xcode 6 beta. (Xcode 5 is hitting the dependency checker crasher on all my systems). llvm-svn: 211526
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-132-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done. This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression. I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData. I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included. A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite. Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub. The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages. I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread. I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably. Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use. I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result. llvm-svn: 210874
* Add support for inspecting enum members.Todd Fiala2014-06-023-0/+136
| | | | | | | | | Change by Russell Harmon. Xcode project updates (and all errors therein) by Todd Fiala. llvm-svn: 210046
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-172-1/+7
| | | | | | | | | | | | | | | | | | | | | | Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
* Add a new SBThread::SafeToCallFunctions API; this calls over toJason Molenda2014-05-131-0/+10
| | | | | | | | | | the SystemRuntime to check if a thread will have any problems performing an inferior function call so the driver can skip making that function call on that thread. Often the function call can be executed on another thread instead. <rdar://problem/16777874> llvm-svn: 208732
* Allow clients to control the exact path that is used to launch processes by ↵Greg Clayton2014-05-071-0/+6
| | | | | | | | | | | | | | | | adding new calls to SBLaunchInfo. The new calls are: SBFileSpec SBLaunchInfo::GetExecutableFile (); void SBLaunchInfo::SetExecutableFile (SBFileSpec exe_file, bool add_as_first_arg); <rdar://problem/16833939> llvm-svn: 208245
* If CMake finds a python interpreter, use itEd Maste2014-05-071-4/+6
| | | | | | | | | | | | | | The FreeBSD package building cluster installs e.g. 'python2.7', but no plain 'python' to avoid version-related issues. CMake's FindPythonInterp locates an interpreter with such a name and provides it in the PYTHON_EXECUTABLE variable. Use that if it's set, falling back to the original '/usr/bin/env python' otherwise. This is a missing part of LLDB commit r207122. Patch by Brooks Davis in FreeBSD ports commit r353052 llvm-svn: 208204
* Add a new SBThread::GetQueue() method to get the queue that is Jason Molenda2014-04-251-0/+13
| | | | | | | | | | currently associated with a given thread, on relevant targets. Change the queue detection code to verify that the queues associated with all live threads are included in the list. <rdar://problem/16411314> llvm-svn: 207160
* If CMake finds a python interpreter, use itEd Maste2014-04-241-3/+4
| | | | | | | | | | | | | The FreeBSD package building cluster installs e.g. 'python2.7', but no plain 'python' to avoid version-related issues. CMake's FindPythonInterp locates an interpreter with such a name and provides it in the PYTHON_EXECUTABLE variable. Use that if it's set, falling back to the original '/usr/bin/env python' otherwise. Patch by Brooks Davis in FreeBSD ports commit r352012 llvm-svn: 207122
* Add the ability to set python breakpoint commands from the SBBreakpoint & ↵Jim Ingham2014-04-022-1/+44
| | | | | | | | | | | 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
* lldb arm64 import.Jason Molenda2014-03-292-0/+10
| | | | | | | | | | | | | | | | These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
* Add the ability from the SB API's to set the "one thread" timeoutJim Ingham2014-03-281-0/+7
| | | | | | | | for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
* Move LLDBWrapPython.cpp into the build folder for Xcode builds so it doesn't ↵Greg Clayton2014-03-141-6/+1
| | | | | | muck with cmake builds. llvm-svn: 203956
* Add a SBQueue::GetKind() method to retrieve the type of libdispatch queue ↵Jason Molenda2014-03-131-0/+18
| | | | | | | | (serial or concurrent). <rdar://problem/7964505> llvm-svn: 203748
* libBacktraceRecording __introspection_dispatch_queue_get_pending_items isJason Molenda2014-03-091-0/+3
| | | | | | | | | | | changing the data it returns; this change accepts either the old format or the new format. It doesn't yet benefit from the new format's additions - but I need to get this checked in so we aren't rev-locked. Also add a missing .i entry for SBQueue::GetNumRunningItems() missing from the last checkin. <rdar://problem/16272115> llvm-svn: 203421
* Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, ↵Jim Ingham2014-02-281-0/+7
| | | | | | | | | and make it work in RunThreadPlan. Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is in the EvaluateExpressionOptions the plan was passed when created it won't work correctly. llvm-svn: 202464
* * Rename PYTHON_INCLUDES to PYTHON_INC_DIR to match the similar declarationSylvestre Ledru2014-02-261-2/+2
| | | | | | | | in lldb.svn/Makefile * Use CPP.Flags to export the declaration. The current solution broke all builds on http://llvm-jenkins.debian.net/ llvm-svn: 202270
* Suppress python readline module under Linux to fix a seg fault.Todd Fiala2014-02-266-0/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
* Make sure we don't try to print the SystemExit exception, or we will cause ↵Enrico Granata2014-02-181-1/+1
| | | | | | the containing process to exit() from under us llvm-svn: 201600
* Change the Mac OS X SystemRuntime plugin from using the placeholderJason Molenda2014-02-052-2/+21
| | | | | | | | | | | | | | libldi library to collect extended backtrace information; switch to the libBacktraceRecording library and its APIs. Complete the work of adding QueueItems to Queues and allow for the QueueItems to be interrogated about their extended backtraces in turn. There's still cleanup and documentation to do on this code but the code is functional and I it's a good time to get the work-in-progress checked in. <rdar://problem/15314027> llvm-svn: 200822
* <rdar://problem/15936507>Enrico Granata2014-01-291-0/+1
| | | | | | | | PyTuple_SetItem steals a reference to the item it inserts in the tuple This, plus the Py_XDECREF of the tuple a few lines below, causes our session dictionary to go away after the first time a SWIG layer function is called - with disastrous effects for the first subsequent attempt to use any functionality in ScriptInterpreterPython This fixes it llvm-svn: 200429
* Merging the iohandler branch back into main. Greg Clayton2014-01-278-155/+13
| | | | | | | | | | | | 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
* Added the ability to get the type that a typedef points to via:Greg Clayton2014-01-232-0/+6
| | | | | | | | | | SBType SBType::GetTypedefedType(); Also added the ability to get a type by type ID from a SBModule: SBType SBModule::GetTypeByID (lldb::user_id_t uid); llvm-svn: 199939
* Patch by Ari GrantEnrico Granata2014-01-091-1/+1
| | | | | | | | | | | | | | | "Open LLDB and run: (lldb) script print lldb.debugger.GetInputFileHandle() This puts the debugger into a catatonic state and all interactions seem to enter a black hole. The reason is that executing this commnand actually *CLOSES* the input file handle and so all input is dropped on the floor. Oof! The fix is simple: flush a descriptor, instead of closing it, when transferring ownership." llvm-svn: 198835
* Add a new way to bind a format to a type: by enum typeEnrico Granata2013-12-281-0/+8
| | | | | | | | | | | The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type, LLDB will display it as-if it was of enumeration type <sometype> This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type, but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges) The SB API has also been improved to handle both types of formats, and a test case is added llvm-svn: 198105
* Adding a document that describes the architecture of data formatters. ↵Enrico Granata2013-12-261-3/+1
| | | | | | Suggestions and ideas for improvements most welcome llvm-svn: 198038
* Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to representJason Molenda2013-12-134-0/+113
| | | | | | | | | libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
* As consistency, invoke python with /usr/bin/env (like it is done in the rest ↵Sylvestre Ledru2013-12-101-1/+1
| | | | | | of the file). Thanks to Xavier De Gaye for the patch llvm-svn: 196933
* For logical backtrace work, lldb needs to track Module unloads etc & ↵Greg Clayton2013-12-061-0/+3
| | | | | | | | | | symoblicate an address based on a point in time <rdar://problem/15314403> This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future. llvm-svn: 196557
* Change lldb from building against a Python framework out ofJason Molenda2013-11-232-68/+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
* Expose SBPlatform through the public API.Greg Clayton2013-11-206-0/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
* Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() methodJason Molenda2013-11-161-1/+13
| | | | | | | | | | (and same thing to Thread base class) which can be used when looking at an ExtendedBacktrace thread; it will try to find the IndexID() of the original thread that was executing this backtrace when it was recorded. If lldb can't find a record of that thread, it will return the same value as IndexID() for the ExtendedBacktrace thread. llvm-svn: 194912
* Change SBThread::GetExtendedBacktrace toJason Molenda2013-11-121-2/+2
| | | | | | | SBThread::GetExtendedBacktraceThread to make it more clear what is being returned. llvm-svn: 194531
OpenPOWER on IntegriCloud