summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python
Commit message (Collapse)AuthorAgeFilesLines
...
* modify-python-lldb.py: Insert initialization code with swig insteadPavel Labath2019-04-051-7/+0
| | | | | | | | This is the last functional change to the generated python module being done by modify-python-lldb.py. The remaining code just deals with reformatting of comments. llvm-svn: 357755
* modify-python-lldb.py: (Re)move __len__ and __iter__ supportPavel Labath2019-04-041-100/+3
| | | | | | | | | | | | | | | | Summary: This patch moves the modify-python-lldb code for adding new functions to the SBModule class into the SBModule interface file. As this is the last class using this functionality, I also remove all support for this kind of modifications from modify-python-lldb.py. Reviewers: amccarth, clayborg, jingham Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D60195 llvm-svn: 357680
* modify-python-lldb.py: clean up __iter__ and __len__ supportPavel Labath2019-04-031-35/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of modifying the swig-generated code, just add the appropriate methods to the interface files in order to get the swig to do the generation for us. This is a straight-forward move from the python script to the interface files. The single class which has nontrivial handling in the script (SBModule) has been left for a separate patch. For the cases where I did not find any tests exercising the iteration/length methods (i.e., no tests failed after I stopped emitting them), I tried to add basic tests for that functionality. Reviewers: zturner, jingham, amccarth Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D60119 llvm-svn: 357572
* Make operator==s consistent between c++ and python APIsPavel Labath2019-04-021-43/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: modify-python-lldb.py had code to insert python equality operators to some classes. Some of those classes already had c++ equality operators, and some didn't. This makes the situation more consistent, by removing all equality handilng from modify-python-lldb. Instead, I add c++ operators to classes where they were missing, and expose them in the swig interface files so that they are available to python too. The only tricky case was the SBAddress class, which had an operator== defined as a free function, which is not handled by swig. This function cannot be removed without breaking ABI, and we cannot add an extra operator== member, as that would make equality comparisons ambiguous. For this class, I define a python __eq__ function by hand and have it delegate to the operator!=, which I have defined as a member function. This isn't fully NFC, as the semantics of some equality functions in python changes slightly, but I believe it changes for the better (e.g., previously SBBreakpoint.__eq__ would consider two breakpoints with the same ID as equal, even if they belonged to different targets; now they are only equal if they belong to the same target). Reviewers: jingham, clayborg, zturner Subscribers: jdoerfert, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D59819 llvm-svn: 357463
* [Python] Remove readline moduleJonas Devlieghere2019-03-293-125/+0
| | | | | | | | | | | Todd added this empty readline module to workaround an issue with an old version of Python on Ubuntu in 2014 (18841). In the meantime, libedit seems to have fixed the underlying issue, and indeed, I wasn't able to reproduce this. Differential revision: https://reviews.llvm.org/D59972 llvm-svn: 357277
* Fix the swig typemap for "uint32_t *versions, uint32_t num_versions".Jim Ingham2019-03-281-10/+5
| | | | | | | | | It was making a list of a certain size but not always filling in that many elements, which would lead to a crash iterating over the list. Differential Revision: https://reviews.llvm.org/D59913 llvm-svn: 357207
* Python 2/3 compatibility: from __future__ import print_functionSerge Guelton2019-03-211-11/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D59580 llvm-svn: 356695
* Fix/unify SBType comparisonPavel Labath2019-03-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In my next step at cleaning up modify-python-lldb.py, I started focusing on equality comparison. To my surprise, I found out that both python and c++ versions of the SBType class implement equality comparison, but each one does it differently. While the python version was implemented in terms of type name equality, the C++ one used a deep comparison on the underlying objects. Removing the python version caused one test to fail (TestTypeList). This happened because the c++ version of operator== boiled down to TypePair::operator==, which contains two items: the compiler_type and type_sp. In this case, the compiler_type was identical, but one of the objects had the type_sp field unset. I tried fixing the code so that both objects keep their type_sp member, but it wasn't easy, because there are so many operations which just work with the CompilerType types, and so any operation on the SBType (the test in question was doing GetPointeeType on the type of one variable and expecting it to match the type of another variable), cause that second member to be lost. So instead, here I relax the equality comparison on the TypePair class. Now, this class ignores the type_sp for the purposes of comparison, and uses the CompilerType only. This seems reasonable, as each TypeSP is able to convert itself to a CompilerType. Reviewers: clayborg, aprantl, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D59217 llvm-svn: 356048
* Add "operator bool" to SB APIsPavel Labath2019-03-111-15/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't. This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files. In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups. Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58792 llvm-svn: 355824
* Insert blocks of python code with swig instead of modify-python-lldb.pyPavel Labath2019-02-271-125/+0
| | | | | | | | | | | | | | | | | | | Summary: Swig is perfectly capable of inserting blocks of python code into its output (and we use those fascilities already), so there's no need for this to be done in a post-process step. lldb_iter is a general-purpose utility used from many classes, so I add it to the main swig file. The other two blocks are tied to a specific class, so I add it to the interface file of that class. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58350 llvm-svn: 354975
* Embed swig version into lldb.py in a different wayPavel Labath2019-02-151-22/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing string chopping on the resulting python file, get swig to output the version for us. The two things which make slightly non-trivial are: - in order to get swig to expand SWIG_VERSION for us, we cannot use %pythoncode directly, but we have to go through an intermediate macro. - SWIG_VERSION is a hex number, but it's components are supposed to be interpreted decimally, so there is a bit of integer magic needed to get the right number to come out. I've tested that this approach works both with the latest (3.0.12) and oldest (1.3.40) supported swig. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58172 llvm-svn: 354104
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Python] Update PyString_FromString() to work for python 2 and 3.Davide Italiano2019-01-092-10/+3
| | | | | | | | | | Reviewers: aprantl, JDevlieghere, friss, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56511 llvm-svn: 350769
* [lldb] Introduce StackFrameRecognizer [take 3]Kuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345693
* Revert r345686 due to build failuresKuba Mracek2018-10-311-46/+0
| | | | llvm-svn: 345688
* [lldb] Introduce StackFrameRecognizer [take 2]Kuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345686
* Revert r345678 (build failure on Linux machines).Kuba Mracek2018-10-311-46/+0
| | | | llvm-svn: 345680
* [lldb] Introduce StackFrameRecognizerKuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345678
* [Swig] Merge typemaps with same bodiesTatyana Krasnukha2018-09-251-196/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D52376 llvm-svn: 342959
* Add a "scripted" breakpoint type to lldb.Jim Ingham2018-09-132-0/+109
| | | | | | | | | | This change allows you to write a new breakpoint type where the logic for setting breakpoints is determined by a Python callback written using the SB API's. Differential Revision: https://reviews.llvm.org/D51830 llvm-svn: 342185
* Remove undefined behavior around the use of StateTypeShafik Yaghmour2018-09-111-0/+20
| | | | | | | | | | rdar://problem/43530233 Patch by Shafik Yaghmour. Differential Revision: https://reviews.llvm.org/D51445 llvm-svn: 341957
* Hold GIL while allocating memory for PythonString.Tatyana Krasnukha2018-09-051-0/+82
| | | | | | | | | | | | | | Summary: Swig wraps C++ code into SWIG_PYTHON_THREAD_BEGIN_ALLOW; ... SWIG_PYTHON_THREAD_END_ALLOW; Thus, LLDB crashes with "Fatal Python error: Python memory allocator called without holding the GIL" when calls an lldb_SB***___str__ function. Reviewers: clayborg Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D51569 llvm-svn: 341482
* Fix and simplify lldb.command decoratorDave Lee2018-07-041-19/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes one issue with `lldb.command`, and also reduces the implementation. The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`. Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously. Additionally, the implementation was updated to: * Remove inner class * Remove use of `inspect` module * Remove `*args` and `**kwargs` Reviewers: clayborg Reviewed By: clayborg Subscribers: keith, xiaobai, lldb-commits Differential Revision: https://reviews.llvm.org/D48658 llvm-svn: 336287
* Python: adjust the include directoriesSaleem Abdulrasool2018-06-041-6/+5
| | | | | | | Restructure the include search order to adjust for libedit. This ensures that the variables are not unused if they are not defined. llvm-svn: 333863
* build: use cmake to find the libedit contentSaleem Abdulrasool2018-05-221-1/+4
| | | | | | | | Use proper cmake techniques to detect where the libedit package resides. This allows for the use of libedit from an alternative location which is needed for supporting cross-compilation. llvm-svn: 333041
* Change SBProcess::ReadCStringFromMemory() back to returningJason Molenda2017-12-221-1/+2
| | | | | | | | | an empty Python string object when it reads a 0-length string out of memory (and a successful SBError object). <rdar://problem/26186692> llvm-svn: 321338
* Make breakpoint names real entities.Jim Ingham2017-09-142-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introduced, breakpoint names were just tags that you could apply to breakpoints that would allow you to refer to a breakpoint when you couldn't capture the ID, or to refer to a collection of breakpoints. This change makes the names independent holders of breakpoint options that you can then apply to breakpoints when you add the name to the breakpoint. It adds the "breakpoint name configure" command to set up or reconfigure breakpoint names. There is also full support for then in the SB API, including a new SBBreakpointName class. The connection between the name and the breakpoints sharing the name remains live, so if you reconfigure the name, all the breakpoint options all change as well. This allows a quick way to share complex breakpoint behavior among a bunch of breakpoints, and a convenient way to iterate on the set. You can also create a name from a breakpoint, allowing a quick way to copy options from one breakpoint to another. I also added the ability to make hidden and delete/disable protected names. When applied to a breakpoint, you will only be able to list, delete or disable that breakpoint if you refer to it explicitly by ID. This feature will allow GUI's that need to use breakpoints for their own purposes to keep their breakpoints from getting accidentally disabled or deleted. <rdar://problem/22094452> llvm-svn: 313292
* Fix a python object leak in SWIG glue.Zachary Turner2017-06-211-1/+2
| | | | | | | | | | PyObject_CallFunction returns a PyObject which needs to be decref'ed when it is no longer needed. Patch by David Luyer Differential Revision: https://reviews.llvm.org/D33740 llvm-svn: 305873
* Install six.py conditionallyKamil Rytarowski2017-02-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current version of LLDB installs six.py into global python library directory. This approach produces conflicts downstream with distribution's py-six copy. Introduce new configure option LLDB_USE_SYSTEM_SIX (disabled by default). Once specified as TRUE, six.py won't be installed to Python's directory. Add new option in finishSwigWrapperClasses.py, namely --useSystemSix. Sponsored by <The NetBSD Foundation> Reviewers: mgorny, emaste, clayborg, joerg, labath Reviewed By: labath Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29405 llvm-svn: 294071
* Fix the cmake declaration syntaxSylvestre Ledru2016-12-171-1/+1
| | | | llvm-svn: 290045
* Support of lldb on Kfreebsd Sylvestre Ledru2016-12-171-1/+1
| | | | | | | | | | | | | | Summary: Patch by Pino Toscano. Reported in http://bugs.debian.org/835665 Reviewers: tfiala, emaste Subscribers: beanz, mgorny, emaste, krytarowski, brucem, tberghammer, danalbert, srhines, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D23977 llvm-svn: 290044
* Fix broken escaping of commands in the buildLuke Drummond2016-12-161-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | A combination of broken escaping in CMake and in the python swig generation scripts meant that the swig generation step would fail whenever there were spaces or special characters in parameters passed to swig. The fix for this in CMakeLists is to use the VERBATIM option on all COMMAND-based custom builders relying on CMake to properly escape each argument in the generated file. Within the python swig scripts, the fix is to call subprocess.Popen with a list of raw argument strings rather than ones that are incorrectly manually escaped, then passed to a shell subprocess via subprocess.Popen(' '.join(params)). This also prevents nasty things happening such as accidental command-injection. This allows us to have the swig / python executables in paths containing special chars and spaces, (or on shared storage on Win32, e.g \\some\path or C:\Program Files\swig\swig.exe). Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26757 llvm-svn: 289956
* Clean up some use of __ANDROID_NDK__ in the cmake filesPavel Labath2016-12-051-1/+1
| | | | | | | | | | | | | | | Rationale: scripts/Python/modules: android is excluded at a higher level, so no point in checking here tools/lldb-mi: lldb-mi builds fine (with some cosmetic tweaks) on android, and there is no reason it shouldn't. tools/lldb-server: LLDB_DISABLE_LIBEDIT/CURSES already take the platform into account, so there is no point in checking again. I am reasonably confident this should not break the build on any platform, but I'll keep an eye out on the bots. llvm-svn: 288661
* [CMake] Rename lldb-launcher to darwin-debugChris Bieneman2016-10-272-41/+0
| | | | | | | | | | | | Summary: This tool is only built on Darwin, and the name darwin-debug matches the Xcode project. We should have this in sync unless there is a good reason not to. Reviewers: zturner, tfiala, labath Subscribers: labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D25745 llvm-svn: 285356
* Fix Python binding generation build step on WindowsVadim Macagon2016-10-131-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: If Python is installed to a location that contains spaces (e.g. "C:\Program Files\Python3") then the build fails while attempting to run the modify-python-lldb.py script because the path to the Python executable is not double-quoted before being passed to the shell. The fix consists of letting Python handle the formatting of the command line, since subprocess.Popen() is perfectly capable of handling paths containing spaces if it's given the command and arguments as a list instead of a single pre-formatted string. Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D25396 llvm-svn: 284100
* [CMake] Initial support for LLDB.frameworkChris Bieneman2016-09-211-4/+4
| | | | | | | | | | | | | | | | | | | Summary: This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library. With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow. The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step. With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up. Reviewers: zturner, tfiala Subscribers: beanz, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D24749 llvm-svn: 282110
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-067-337/+544
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fixup TestPyObjSynthProvider.py and enable it againPavel Labath2016-08-311-0/+1
| | | | | | | | | | | | | | | Summary: - copies the new file in the cmake build - adds an additional import statement - marks the test as no-debug-info specific, as it seems to be testing a python feature Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24074 llvm-svn: 280261
* Add an helper class lldb.formatters.synth.PythonObjectSyntheticChildProviderEnrico Granata2016-08-301-0/+1
| | | | | | | | This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues Comes with a test case llvm-svn: 280172
* Add .i files for SBMemoryRegionInfo and SBMemoryRegionInfoList and also hook ↵Greg Clayton2016-06-241-0/+16
| | | | | | | | up the new calls in SBProcess that give out SBMemoryRegionInfo and SBMemoryRegionInfoList objects. Also make sure the right headers and .i files are included so SWIG can hook everything up. llvm-svn: 273749
* Fix an issue where the @lldb.command marker would not work with the new ↵Enrico Granata2016-06-242-5/+10
| | | | | | | | | | | 5-argument version of the Python command function This: a) teaches PythonCallable to look inside a callable object b) teaches PythonCallable to discover whether a callable method is bound c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version llvm-svn: 273640
* Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is usedFrancis Ricci2016-04-251-6/+36
| | | | | | | | | | | | | | | | Summary: Do not assume that liblldb.so is located in $(lldb -P)/../../../lib when creating the _lldb python symlink. Instead, use the path passed to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this variable is not set. Reviewers: vharron, emaste, zturner Subscribers: zturner, labath, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19067 llvm-svn: 267462
* Fix #ifdef __APPLE__ code is the swig Python bindingsTodd Fiala2016-04-081-2/+2
| | | | | | | | | | This code was getting evaluated unintentionally at binding generation time instead of binding file compilation time. Addresses: https://bugs.swift.org/browse/SR-1192 llvm-svn: 265829
* Fix a build issue where the python module could become stale.Zachary Turner2016-03-181-4/+17
| | | | | | | | | | | | | | | | | We are using hardlinks instead of symlinks, and we attempted to have some logic where we don't re-create the link if the target file already exists. This logic is faulty, however, when you manually delete the source file (e.g. liblldb.dll) and then rebuild lldb so that a brand new liblldb.dll gets written. Now the two files have different inodes, but the target exists, so we would not remake the link and the target would become stale. We fix this by only doing the optimization if they are really the exact same file (by comparing inode numbers), and if they are not the same file but the target exists, we delete it and re-create the link. llvm-svn: 263844
* Check for a NULL input filehandle before referencing it.Jim Ingham2016-03-111-8/+11
| | | | | | <rdar://problem/25105824> llvm-svn: 263274
* Fix SBDebugger.GetOutputFileHandle() on OS X.Jim Ingham2016-03-112-2/+4
| | | | | | | | | | | | | | | | | | | | | | | The swig typemaps had some magic for output File *'s on OS X that made: SBDebugger.GetOutputFileHandle() actually work. That was protected by a "#ifdef __MACOSX__", but the corresponding define got lost going from the Darwin shell scripts to the python scripts for running swig, so the code was elided. I need to pass the define to SWIG, but only when targetting Darwin. So I added a target-platform argument to prepare_bindings, and if that is Darwin, I pass -D__APPLE__ to swig, and that activates this code again, and GetOutputFileHandle works again. Note, I only pass that argument for the Xcode build. I'm sure it is possible to do that for cmake, but my cmake-foo is weak. I should have been able to write a test for this by creating a debugger, setting the output file handle to something file, writing to it, getting the output file handle and reading it. But SetOutputFileHandle doesn't seem to work from Python, so I'd have to write a pexpect test to test this, which I'd rather not do. llvm-svn: 263183
* Adjust for Python-3.Siva Chandra2016-02-121-5/+29
| | | | | | | | | | | | | | | Summary: This does not yet give us a clean testsuite run but it does help with: 1. Actually building on linux 2. Run the testsuite with over 70% tests passing on linux. Reviewers: tfiala, labath, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17182 llvm-svn: 260721
* Change lldb.value.__int__() so that it takes into account the signedness of ↵Enrico Granata2016-02-101-3/+48
| | | | | | | | | | the value being cast to return a Python number with the proper value The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless Fixes rdar://24556976 llvm-svn: 260349
* Remove autoconf support from source directories.Eugene Zelenko2016-01-283-135/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Fix some issues with bytes and strings in Python 3.Zachary Turner2016-01-251-3/+8
| | | | | | | | | | | | | | | | | | SBProcess::ReadMemory and other related functions such as WriteMemory are returning Python string() objects. This means that in Python 3 that are returning Unicode objects. In reality they should be returning bytes objects which is the same as a string in Python 2, but different in Python 3. This patch updates the generated SWIG code to return Python bytes objects for all memory related functions. One quirk of this patch is that the C++ signature of ReadCStringFromMemory has it writing c-string data into a void*. This confuses our swig typemaps which expect that a void* means byte data. So I hacked up a custom typemap which maps this specific function to treat the void* as string data instead of byte data. llvm-svn: 258743
OpenPOWER on IntegriCloud