maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/scripts/Python/build-swig-Python.sh

321 lines
10 KiB
Bash
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#!/bin/sh
# build-swig-Python.sh
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
# SRC_ROOT is the root of the lldb source tree.
# TARGET_DIR is where the lldb framework/shared library gets put.
# CONFIG_BUILD_DIR is where the build-swig-Python-LLDB.sh shell script
# put the lldb.py file it was generated from running SWIG.
# PREFIX is the root directory used to determine where third-party modules
# for scripting languages should be installed.
# debug_flag (optional) determines whether or not this script outputs
# additional information when running.
SRC_ROOT=$1
TARGET_DIR=$2
CONFIG_BUILD_DIR=$3
PYTHON_INSTALL_DIR=$4
debug_flag=$5
Look for swig in /usr/bin and /usr/local/bin. llvm-svn: 126732
2011-03-01 09:39:04 +08:00
SWIG=$6
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
Fixed some problems with SWIG bindings. 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
2012-09-15 01:09:15 +08:00
os_name=`uname -s`
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ "$os_name" = "Darwin" ]
Fixed some problems with SWIG bindings. 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
2012-09-15 01:09:15 +08:00
then
swig_output_file=${SRC_ROOT}/source/LLDBWrapPython.cpp
else
swig_output_file=${TARGET_DIR}/LLDBWrapPython.cpp
fi
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
swig_input_file=${SRC_ROOT}/scripts/lldb.swig
Check the timesatmps of includees python-extensions.swig and python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
2011-08-23 06:10:57 +08:00
swig_python_extensions=${SRC_ROOT}/scripts/Python/python-extensions.swig
swig_python_wrapper=${SRC_ROOT}/scripts/Python/python-wrapper.swig
ensure that changes to the typemaps are properly detected and cause SWIG to rebuild LLDBWrapPython.cpp llvm-svn: 149606
2012-02-03 01:26:00 +08:00
swig_python_typemaps=${SRC_ROOT}/scripts/Python/python-typemaps.swig
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed some problems with SWIG bindings. 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
2012-09-15 01:09:15 +08:00
if [ "$LLDB_DISABLE_PYTHON" = "1" ] ; then
Fix the comments about LLDB_DISABLE_PYTHON in the python swig shell scripts to be more clear. llvm-svn: 157506
2012-05-26 08:23:52 +08:00
# We don't want Python for this build, but touch the output file so we don't have to
# conditionalize the build on this as well.
# Note, at present iOS doesn't have Python, so if you're building for iOS be sure to
# set LLDB_DISABLE_PYTHON to 1.
Change the "Debug" build to use the current MacOSX SDK. Fix the swig builder to have an explicit short-circuit of the Python SWIG building, rather than relying on the SDKROOT being set. llvm-svn: 157363
2012-05-24 09:16:09 +08:00
rm -rf ${swig_output_file}
touch ${swig_output_file}
else
Fixed the Xcode project building of LLVM to be a bit more user friendly: - 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
2011-11-04 11:34:56 +08:00
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ -n "$debug_flag" -a "$debug_flag" = "-debug" ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
Debug=1
else
Debug=0
fi
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python 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
2012-02-21 13:33:55 +08:00
# If this project is being built with LLDB_DISABLE_PYTHON defined,
# don't bother generating Python swig bindings -- we don't have
# Python available.
if echo $GCC_PREPROCESSOR_DEFINITIONS | grep LLDB_DISABLE_PYTHON
then
echo "" > "${swig_output_file}"
exit 0
fi
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed the LLDB build so that we can have private types, private enums and 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
2011-03-25 05:19:54 +08:00
HEADER_FILES="${SRC_ROOT}/include/lldb/lldb.h"\
Add header files that were added to lldb.swig to the build script, so it can keep track of dependencies accurately (for knowing when to re-build LLDBWrapPython.cpp). llvm-svn: 116765
2010-10-19 07:00:51 +08:00
" ${SRC_ROOT}/include/lldb/lldb-defines.h"\
" ${SRC_ROOT}/include/lldb/lldb-enumerations.h"\
" ${SRC_ROOT}/include/lldb/lldb-forward.h"\
" ${SRC_ROOT}/include/lldb/lldb-forward-rtti.h"\
" ${SRC_ROOT}/include/lldb/lldb-types.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBAddress.h"\
" ${SRC_ROOT}/include/lldb/API/SBBlock.h"\
" ${SRC_ROOT}/include/lldb/API/SBBreakpoint.h"\
" ${SRC_ROOT}/include/lldb/API/SBBreakpointLocation.h"\
" ${SRC_ROOT}/include/lldb/API/SBBroadcaster.h"\
" ${SRC_ROOT}/include/lldb/API/SBCommandInterpreter.h"\
" ${SRC_ROOT}/include/lldb/API/SBCommandReturnObject.h"\
Cleaned up the SWIG stuff so all includes happen as they should, no pulling 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
2010-10-07 12:19:01 +08:00
" ${SRC_ROOT}/include/lldb/API/SBCommunication.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBCompileUnit.h"\
Redesign of the interaction between Python and frozen objects: - 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
2011-09-07 03:20:51 +08:00
" ${SRC_ROOT}/include/lldb/API/SBData.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBDebugger.h"\
" ${SRC_ROOT}/include/lldb/API/SBError.h"\
" ${SRC_ROOT}/include/lldb/API/SBEvent.h"\
o Exposed SBFileSpec to the Python APIs in lldb.py. o Fixed a crasher when getting it via SBTarget.GetExecutable(). >>> filespec = target.GetExecutable() Segmentation fault o And renamed SBFileSpec::GetFileName() to GetFilename() to be consistent with FileSpec::GetFilename(). llvm-svn: 112308
2010-08-28 06:35:26 +08:00
" ${SRC_ROOT}/include/lldb/API/SBFileSpec.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBFrame.h"\
" ${SRC_ROOT}/include/lldb/API/SBFunction.h"\
Cleaned up the SWIG stuff so all includes happen as they should, no pulling 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
2010-10-07 12:19:01 +08:00
" ${SRC_ROOT}/include/lldb/API/SBHostOS.h"\
" ${SRC_ROOT}/include/lldb/API/SBInputReader.h"\
Added the ability to get the disassembly instructions from the function and symbol. llvm-svn: 115734
2010-10-06 11:09:58 +08:00
" ${SRC_ROOT}/include/lldb/API/SBInstruction.h"\
" ${SRC_ROOT}/include/lldb/API/SBInstructionList.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBLineEntry.h"\
" ${SRC_ROOT}/include/lldb/API/SBListener.h"\
" ${SRC_ROOT}/include/lldb/API/SBModule.h"\
" ${SRC_ROOT}/include/lldb/API/SBProcess.h"\
" ${SRC_ROOT}/include/lldb/API/SBSourceManager.h"\
Remove SBCommandContext which was not needed or doing anything. Add SBValueList.h & SBStream.h to build-swig-Python.sh; add SBValueList.h to lldb.swig llvm-svn: 114549
2010-09-23 00:41:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBStream.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBStringList.h"\
" ${SRC_ROOT}/include/lldb/API/SBSymbol.h"\
" ${SRC_ROOT}/include/lldb/API/SBSymbolContext.h"\
Cleaned up the SWIG stuff so all includes happen as they should, no pulling 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
2010-10-07 12:19:01 +08:00
" ${SRC_ROOT}/include/lldb/API/SBSymbolContextList.h"\
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBTarget.h"\
" ${SRC_ROOT}/include/lldb/API/SBThread.h"\
" ${SRC_ROOT}/include/lldb/API/SBType.h"\
<rdar://problem/10062621> 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
2012-02-15 10:34:21 +08:00
" ${SRC_ROOT}/include/lldb/API/SBTypeCategory.h"\
" ${SRC_ROOT}/include/lldb/API/SBTypeFilter.h"\
" ${SRC_ROOT}/include/lldb/API/SBTypeFormat.h"\
" ${SRC_ROOT}/include/lldb/API/SBTypeNameSpecifier.h"\
" ${SRC_ROOT}/include/lldb/API/SBTypeSummary.h"\
" ${SRC_ROOT}/include/lldb/API/SBTypeSynthetic.h"\
Remove SBCommandContext which was not needed or doing anything. Add SBValueList.h & SBStream.h to build-swig-Python.sh; add SBValueList.h to lldb.swig llvm-svn: 114549
2010-09-23 00:41:52 +08:00
" ${SRC_ROOT}/include/lldb/API/SBValue.h"\
Export the watchpoint related API (SBWatchpointLocation class and added 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
2011-09-27 09:19:20 +08:00
" ${SRC_ROOT}/include/lldb/API/SBValueList.h"\
Implementing plugins that provide commands. 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
2012-09-29 07:57:51 +08:00
" ${SRC_ROOT}/include/lldb/API/SBWatchpoint.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed the error message: ./build-swig-Python.sh: line 76: INTERFACE_FILES: command not found when running SWIG, which was introduced during the last checkin. llvm-svn: 139376
2011-09-10 01:37:06 +08:00
INTERFACE_FILES="${SRC_ROOT}/scripts/Python/interface/SBAddress.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBBlock.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBBreakpoint.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBBreakpointLocation.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBBroadcaster.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBCommandInterpreter.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBCommandReturnObject.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBCommunication.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBCompileUnit.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBData.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBDebugger.i"\
<rdar://problem/12462744> Implement a new SBDeclaration class to wrap an 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
2012-10-11 06:54:17 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBDeclaration.i"\
Fixed the error message: ./build-swig-Python.sh: line 76: INTERFACE_FILES: command not found when running SWIG, which was introduced during the last checkin. llvm-svn: 139376
2011-09-10 01:37:06 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBError.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBEvent.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBFileSpec.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBFrame.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBFunction.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBHostOS.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBInputReader.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBInstruction.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBInstructionList.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBLineEntry.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBListener.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBModule.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBProcess.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBSourceManager.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBStream.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBStringList.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBSymbol.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBSymbolContext.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTarget.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBThread.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBType.i"\
<rdar://problem/10062621> 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
2012-02-15 10:34:21 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBTypeCategory.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTypeFilter.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTypeFormat.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTypeNameSpecifier.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTypeSummary.i"\
" ${SRC_ROOT}/scripts/Python/interface/SBTypeSynthetic.i"\
Fixed the error message: ./build-swig-Python.sh: line 76: INTERFACE_FILES: command not found when running SWIG, which was introduced during the last checkin. llvm-svn: 139376
2011-09-10 01:37:06 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBValue.i"\
Export the watchpoint related API (SBWatchpointLocation class and added 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
2011-09-27 09:19:20 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBValueList.i"\
Cleaned up the SBWatchpoint public API. llvm-svn: 141876
2011-10-14 02:08:26 +08:00
" ${SRC_ROOT}/scripts/Python/interface/SBWatchpoint.i"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
echo "Header files are:"
echo ${HEADER_FILES}
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Redesign of the interaction between Python and frozen objects: - 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
2011-09-07 03:20:51 +08:00
then
echo "SWIG interface files are:"
echo ${INTERFACE_FILES}
fi
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
NeedToUpdate=0
o Added a test case for array_types which uses the Python APIs from lldb.py, with the only exception of launching the process from SBTarget which is under investigation. o build-swig-Python.sh should also checks the timestamp of ${swig_input_file} for update eligibility. Also, once an update is in order, there's no need to check the remaining header files for timestamps. o Coaches swig to treat StopReason as an int type, instead of a C++ class. llvm-svn: 112210
2010-08-27 04:04:17 +08:00
if [ ! -f ${swig_output_file} ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
echo "Failed to find LLDBWrapPython.cpp"
fi
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
for hdrfile in ${HEADER_FILES}
do
o Added a test case for array_types which uses the Python APIs from lldb.py, with the only exception of launching the process from SBTarget which is under investigation. o build-swig-Python.sh should also checks the timestamp of ${swig_input_file} for update eligibility. Also, once an update is in order, there's no need to check the remaining header files for timestamps. o Coaches swig to treat StopReason as an int type, instead of a C++ class. llvm-svn: 112210
2010-08-27 04:04:17 +08:00
if [ $hdrfile -nt ${swig_output_file} ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
echo "${hdrfile} is newer than ${swig_output_file}"
echo "swig file will need to be re-built."
fi
o Added a test case for array_types which uses the Python APIs from lldb.py, with the only exception of launching the process from SBTarget which is under investigation. o build-swig-Python.sh should also checks the timestamp of ${swig_input_file} for update eligibility. Also, once an update is in order, there's no need to check the remaining header files for timestamps. o Coaches swig to treat StopReason as an int type, instead of a C++ class. llvm-svn: 112210
2010-08-27 04:04:17 +08:00
break
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
fi
done
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
Redesign of the interaction between Python and frozen objects: - 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
2011-09-07 03:20:51 +08:00
then
for intffile in ${INTERFACE_FILES}
do
if [ $intffile -nt ${swig_output_file} ]
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Redesign of the interaction between Python and frozen objects: - 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
2011-09-07 03:20:51 +08:00
then
echo "${intffile} is newer than ${swig_output_file}"
echo "swig file will need to be re-built."
fi
break
fi
done
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
o Added a test case for array_types which uses the Python APIs from lldb.py, with the only exception of launching the process from SBTarget which is under investigation. o build-swig-Python.sh should also checks the timestamp of ${swig_input_file} for update eligibility. Also, once an update is in order, there's no need to check the remaining header files for timestamps. o Coaches swig to treat StopReason as an int type, instead of a C++ class. llvm-svn: 112210
2010-08-27 04:04:17 +08:00
then
if [ ${swig_input_file} -nt ${swig_output_file} ]
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
o Added a test case for array_types which uses the Python APIs from lldb.py, with the only exception of launching the process from SBTarget which is under investigation. o build-swig-Python.sh should also checks the timestamp of ${swig_input_file} for update eligibility. Also, once an update is in order, there's no need to check the remaining header files for timestamps. o Coaches swig to treat StopReason as an int type, instead of a C++ class. llvm-svn: 112210
2010-08-27 04:04:17 +08:00
then
echo "${swig_input_file} is newer than ${swig_output_file}"
echo "swig file will need to be re-built."
fi
fi
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
First pass at adding logging capabilities for the API functions. At the moment 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
2010-10-26 11:11:13 +08:00
then
Check the timesatmps of includees python-extensions.swig and python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
2011-08-23 06:10:57 +08:00
if [ ${swig_python_extensions} -nt ${swig_output_file} ]
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
Check the timesatmps of includees python-extensions.swig and python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
2011-08-23 06:10:57 +08:00
then
echo "${swig_python_extensions} is newer than ${swig_output_file}"
echo "swig file will need to be re-built."
fi
fi
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
Check the timesatmps of includees python-extensions.swig and python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
2011-08-23 06:10:57 +08:00
then
if [ ${swig_python_wrapper} -nt ${swig_output_file} ]
First pass at adding logging capabilities for the API functions. At the moment 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
2010-10-26 11:11:13 +08:00
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
First pass at adding logging capabilities for the API functions. At the moment 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
2010-10-26 11:11:13 +08:00
then
Check the timesatmps of includees python-extensions.swig and python-wrapper.swig and force a re-SWIG if newer than the SWIG-generated LLDBWrapPython.cpp file. llvm-svn: 138280
2011-08-23 06:10:57 +08:00
echo "${swig_python_wrapper} is newer than ${swig_output_file}"
First pass at adding logging capabilities for the API functions. At the moment 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
2010-10-26 11:11:13 +08:00
echo "swig file will need to be re-built."
fi
fi
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
ensure that changes to the typemaps are properly detected and cause SWIG to rebuild LLDBWrapPython.cpp llvm-svn: 149606
2012-02-03 01:26:00 +08:00
then
if [ ${swig_python_typemaps} -nt ${swig_output_file} ]
then
NeedToUpdate=1
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $Debug -eq 1 ]
ensure that changes to the typemaps are properly detected and cause SWIG to rebuild LLDBWrapPython.cpp llvm-svn: 149606
2012-02-03 01:26:00 +08:00
then
echo "${swig_python_typemaps} is newer than ${swig_output_file}"
echo "swig file will need to be re-built."
fi
fi
fi
Fixed some problems with SWIG bindings. 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
2012-09-15 01:09:15 +08:00
python_version=`/usr/bin/env python --version 2>&1 | sed -e 's,Python ,,' -e 's,[.][0-9],,2' -e 's,[a-z][a-z][0-9],,'`
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ "$os_name" = "Darwin" ]
Parameterize the shell scripts for creating and copying the python and other script files around, so they can be run from outside Xcode. Also, check the current OS, and only try to use the framework structure stuff on Darwin systems. llvm-svn: 106132
2010-06-17 03:26:52 +08:00
then
framework_python_dir="${TARGET_DIR}/LLDB.framework/Resources/Python"
else
framework_python_dir="${PYTHON_INSTALL_DIR}/python${python_version}"
fi
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if [ ! -L "${framework_python_dir}/_lldb.so" ]
then
NeedToUpdate=1
fi
if [ ! -f "${framework_python_dir}/lldb.py" ]
then
NeedToUpdate=1
fi
Patch from Dan Malea to get the Bourne shells scripts to run cleanly on Ubuntu. llvm-svn: 164801
2012-09-28 05:26:57 +08:00
if [ $NeedToUpdate -eq 0 ]
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
then
echo "Everything is up-to-date."
exit 0
else
echo "SWIG needs to be re-run."
First pass at adding logging capabilities for the API functions. At the moment 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
2010-10-26 11:11:13 +08:00
if [ -f ${swig_output_file} ]
then
rm ${swig_output_file}
fi
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
fi
# Build the SWIG C++ wrapper file for Python.
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 12:14:54 +08:00
$SWIG -c++ -shadow -python -threads -I"/usr/include" -I"${SRC_ROOT}/include" -I./. -outdir "${CONFIG_BUILD_DIR}" -o "${swig_output_file}" "${swig_input_file}"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Update comments. llvm-svn: 130533
2011-04-30 03:22:24 +08:00
# Implement the iterator protocol and/or eq/ne operators for some lldb objects.
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
# Append global variable to lldb Python module.
Move the iteration protocol of lldb objects to the auto-generated lldb 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
2011-04-29 05:31:18 +08:00
# And initialize the lldb debugger subsystem.
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
current_dir=`pwd`
Move the iteration protocol of lldb objects to the auto-generated lldb 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
2011-04-29 05:31:18 +08:00
if [ -f "${current_dir}/modify-python-lldb.py" ]
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
then
Move the iteration protocol of lldb objects to the auto-generated lldb 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
2011-04-29 05:31:18 +08:00
python ${current_dir}/modify-python-lldb.py ${CONFIG_BUILD_DIR}
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
fi
Remove references to particular Python version (use the system default 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
2010-10-29 05:51:20 +08:00
# Fix the "#include" statement in the swig output file
if [ -f "${current_dir}/edit-swig-python-wrapper-file.py" ]
then
python ${current_dir}/edit-swig-python-wrapper-file.py
if [ -f "${swig_output_file}.edited" ]
then
mv "${swig_output_file}.edited" ${swig_output_file}
fi
fi
Fixed the Xcode project building of LLVM to be a bit more user friendly: - 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
2011-11-04 11:34:56 +08:00
fi