summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/build-swig-Python.sh
Commit message (Collapse)AuthorAgeFilesLines
* Remove the scripts/Python/build-swig-Python.sh script.Todd Fiala2015-11-181-378/+0
| | | | | | This logically goes with my previous commit. llvm-svn: 253491
* Add language option in -gdb-show command (MI)Ilia K2015-04-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add language option in -gdb-show command + test: ``` $ bin/lldb-mi ~/p/hello [...] b main [...] r [...] (gdb) -gdb-show language ^done,value="c++" (gdb) quit ``` Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/ Reviewers: abidh, granata.enrico, jingham, clayborg Reviewed By: clayborg Subscribers: lldb-commits, jingham, granata.enrico, clayborg, abidh Differential Revision: http://reviews.llvm.org/D9279 llvm-svn: 235983
* Start to share SWIG interface files between languages.Bruce Mitchener2015-04-241-53/+53
| | | | | | | | | | | | | | | | | | | | Summary: Move scripts/Python/interface to scripts/interface so that we can start making iterative improvements towards sharing the interface files between multiple languages (each of which would have their own directory as now). Test Plan: Build and see. Reviewers: zturner, emaste, clayborg Reviewed By: clayborg Subscribers: mjsabby, lldb-commits Differential Revision: http://reviews.llvm.org/D9212 llvm-svn: 235676
* Revert "Revert "I had recently added a new SBFrame::GetVariables() overload ↵Zachary Turner2015-02-171-0/+2
| | | | | | | | | | | with yet another bool argument"" Reverting this commit led to other failures which I did not see at first. This turned out to be an easy problem to fix, so I added SBVariablesOptions.cpp to the CMakeLists.txt. In the future please try to make sure new files are added to CMake. llvm-svn: 229516
* Revert "I had recently added a new SBFrame::GetVariables() overload with yet ↵Zachary Turner2015-02-171-2/+0
| | | | | | | | | | | | | | another bool argument" This reverts commit r228975. It was causing link errors on the Windows bots, since last Thursday. http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/725 Conflicts: lldb.xcodeproj/project.pbxproj llvm-svn: 229514
* Extract SBAttachInfo into own set of files - SBAttachInfo.h, ↵Oleksiy Vyalov2015-02-161-0/+2
| | | | | | SBAttachInfo.cpp and SBAttachInfo.i. llvm-svn: 229346
* I had recently added a new SBFrame::GetVariables() overload with yet another ↵Enrico Granata2015-02-121-0/+2
| | | | | | | | | | bool argument We talked about it internally - and came to the conclusion that it's time to have an options class This commit adds an SBVariablesOptions class and goes through all the required dance llvm-svn: 228975
* Extend SBPlatform with capability to launch/terminate a process remotely. ↵Oleksiy Vyalov2015-02-041-0/+2
| | | | | | | | Integrate this change into test framework in order to spawn processes on a remote target. http://reviews.llvm.org/D7263 llvm-svn: 228230
* Add a new SBExecutionContext class that wraps an ExecutionContextRef. This ↵Enrico Granata2014-10-011-0/+2
| | | | | | class is a convenient way at the API level to package a target,process,thread and frame all together - or just a subset of those llvm-svn: 218808
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-0/+2
| | | | | | | | | | | | 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
* Expose ThreadCollection in SB APIKuba Brecka2014-09-061-0/+2
| | | | | | | | | 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
* Add API control of the signal disposition.Todd Fiala2014-06-231-2/+4
| | | | | | | | | | | | 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
* 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
* 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
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-2/+0
| | | | | | | | | | | | 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
* Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to representJason Molenda2013-12-131-0/+4
| | | | | | | | | 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
* Change lldb from building against a Python framework out ofJason Molenda2013-11-231-15/+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-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Added a way to extract the module specifications from a file. A module ↵Greg Clayton2013-07-081-0/+2
| | | | | | | | | | | | | specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files). There are two new classes: lldb::SBModuleSpec lldb::SBModuleSpecList The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList. llvm-svn: 185877
* Change the SWIG wrappers to stop directly casting SB object to SWIG objects, ↵Enrico Granata2013-06-211-0/+14
| | | | | | | | | | | and instead use a safer type-checked API (thanks templates) Any time a SWIG wrapper needs a PyObject for an SB object, it now should call into SBTypeToSWIGWrapper<SBType>(SBType*) If you try to use it on an SBType for which there is not an implementation yet, LLDB will fail to link - just add your specialization to python-swigsafecast.swig and rebuild This is the first step in simplifying our SWIG Wrapper layer llvm-svn: 184580
* Makefile patches from Charles Davis and Daniel Malea (+ one or two tweaks).Filipe Cabecinhas2012-11-011-11/+50
| | | | llvm-svn: 167242
* Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham2012-10-161-0/+2
| | | | | | | | | | "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
* <rdar://problem/12462744> Implement a new SBDeclaration class to wrap an ↵Enrico Granata2012-10-101-0/+1
| | | | | | lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration llvm-svn: 165672
* Implementing plugins that provide commands.Enrico Granata2012-09-281-1/+1
| | | | | | | | | | | | | | | | | | | This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin. Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands Caveats: Currently, the new API objects and features are not exposed via Python. The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object) There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own llvm-svn: 164865
* Patch from Dan Malea to get the Bourne shells scripts to run cleanly on ↵Jason Molenda2012-09-271-19/+19
| | | | | | Ubuntu. llvm-svn: 164801
* Fixed some problems with SWIG bindings.Filipe Cabecinhas2012-09-141-4/+9
| | | | | | | | | | This may (but shouldn't) break Linux (but I tested and it still worked on FreeBSD). The same shell scripts are now used on Xcode and Makefiles, for generating the SWIG bindings. Some compatibility fixes were applied, too (python path, bash-isms, etc). llvm-svn: 163912
* Merge python-GIL bracnh (by filcab) back into trunk!Johnny Chen2012-08-181-1/+1
| | | | llvm-svn: 162161
* Fix the comments about LLDB_DISABLE_PYTHON in the python swig shell scripts ↵Jim Ingham2012-05-261-1/+4
| | | | | | to be more clear. llvm-svn: 157506
* Fix missing Resources/Python directory for macosx build.Johnny Chen2012-05-241-1/+1
| | | | llvm-svn: 157405
* Change the "Debug" build to use the current MacOSX SDK. Fix the swig ↵Jim Ingham2012-05-241-5/+6
| | | | | | | | builder to have an explicit short-circuit of the Python SWIG building, rather than relying on the SDKROOT being set. llvm-svn: 157363
* Patch Enrico's changes from r150558 on 2012-02-14 to build even if PythonJason Molenda2012-02-211-0/+9
| | | | | | | | | | | | is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. llvm-svn: 151035
* <rdar://problem/10062621>Enrico Granata2012-02-151-0/+12
| | | | | | | | | | | | | | | | | | New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
* ensure that changes to the typemaps are properly detected and cause SWIG to ↵Enrico Granata2012-02-021-0/+14
| | | | | | rebuild LLDBWrapPython.cpp llvm-svn: 149606
* Fixed the Xcode project building of LLVM to be a bit more user friendly:Greg Clayton2011-11-041-0/+8
| | | | | | | | | | | | | | | | | | | - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
* Cleaned up the SBWatchpoint public API.Greg Clayton2011-10-131-2/+2
| | | | llvm-svn: 141876
* Export the watchpoint related API (SBWatchpointLocation class and added ↵Johnny Chen2011-09-271-2/+4
| | | | | | | | | | | | | | SBTarget methods) to the Python interface. Implement yet another (threre're 3 now) iterator protocol for SBTarget: watchpoint_location_iter(), to iterate on the available watchpoint locations. And add a print representation for SBWatchpointLocation. Exercise some of these Python API with TestWatchpointLocationIter.py. llvm-svn: 140595
* Fixed the error message:Johnny Chen2011-09-091-33/+33
| | | | | | | | ./build-swig-Python.sh: line 76: INTERFACE_FILES: command not found when running SWIG, which was introduced during the last checkin. llvm-svn: 139376
* Redesign of the interaction between Python and frozen objects:Enrico Granata2011-09-061-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
* Check the timesatmps of includees python-extensions.swig and ↵Johnny Chen2011-08-221-4/+17
| | | | | | | | python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
* Update comments.Johnny Chen2011-04-291-1/+1
| | | | llvm-svn: 130533
* Move the iteration protocol of lldb objects to the auto-generated lldb ↵Johnny Chen2011-04-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Python module. This is so that the objects which support the iteration protocol are immediately obvious from looking at the lldb.py file. SBTarget supports two types of iterations: module and breakpoint. For an SBTarget instance, you will need to issue either: for m in target.module_iter() or for b in target.breakpoint_iter() For other single iteration protocol objects, just use, for example: for thread in process: ID = thread.GetThreadID() for frame in thread: frame.Disassemble() .... llvm-svn: 130442
* Fixed the LLDB build so that we can have private types, private enums andGreg Clayton2011-03-241-1/+1
| | | | | | | | public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
* Look for swig in /usr/bin and /usr/local/bin.Jim Ingham2011-03-011-1/+2
| | | | llvm-svn: 126732
* Remove references to particular Python version (use the system defaultCaroline Tice2010-10-281-0/+11
| | | | | | | | | | version); change include statements to use Python.h in the Python framework on Mac OS X systems; leave it using regular Python.h on other systems. Note: I think this *ought* to work properly on Linux systems, but I don't have a system to test it on... llvm-svn: 117612
* First pass at adding logging capabilities for the API functions. At the momentCaroline Tice2010-10-261-0/+18
| | | | | | | | | | | | | | | | | | it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
* Add header files that were added to lldb.swig to the buildCaroline Tice2010-10-181-0/+5
| | | | | | | script, so it can keep track of dependencies accurately (for knowing when to re-build LLDBWrapPython.cpp). llvm-svn: 116765
* Cleaned up the SWIG stuff so all includes happen as they should, no pullingGreg Clayton2010-10-071-2/+6
| | | | | | | | | | | | | | | | | | tricks to get types to resolve. I did this by correctly including the correct files: stdint.h and all lldb-*.h files first before including the API files. This allowed me to remove all of the hacks that were in the lldb.swig file and it also allows all of the #defines in lldb-defines.h and enumerations in lldb-enumerations.h to appear in the lldb.py module. This will make the python script code a lot more readable. Cleaned up the "process launch" command to not execute a "process continue" command, it now just does what it should have with the internal API calls instead of executing another command line command. Made the lldb_private::Process set the state to launching and attaching if WillLaunch/WillAttach return no error respectively. llvm-svn: 115902
* Added the ability to get the disassembly instructions from the function andGreg Clayton2010-10-061-0/+2
| | | | | | symbol. llvm-svn: 115734
* Remove SBCommandContext which was not needed or doing anything.Caroline Tice2010-09-221-2/+3
| | | | | | Add SBValueList.h & SBStream.h to build-swig-Python.sh; add SBValueList.h to lldb.swig llvm-svn: 114549
OpenPOWER on IntegriCloud