summaryrefslogtreecommitdiffstats
path: root/lldb/scripts
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0623-606/+1109
| | | | | | | | | | | | | | | | | | | | | | | *** 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 SBType::GetArrayType() such that - given a type - one can make an array ↵Enrico Granata2016-08-301-0/+3
| | | | | | | | (of a given size) of that type This is currently only implemented for the clang-based TypeSystem, but other languages are welcome to jump in! llvm-svn: 280151
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-194-2/+53
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-194-53/+2
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-194-2/+53
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* fix lldb-gtest target of Xcode buildTodd Fiala2016-08-121-1/+1
| | | | | | | | | | | | | Change r278527 was filtering out too many libraries. The Xcode lldb-gtest target depends on linking libgtest*.a, but those were not being included. This caused the lldb-gtest linkage step to fail to find a main entry point that is present in the filtered out libs. This change restores the libgtest* libraries to the link list by whitelisting them in the filter. llvm-svn: 278552
* Link LLDB only against libclang and libLLVM .a files to fix macOS buildTodd Fiala2016-08-121-1/+4
| | | | | | | | | | | | | | | | | | The Xcode macOS build of LLDB is currently broken after https://reviews.llvm.org/D23232 landed, see http://lab.llvm.org:8080/green/job/lldb_build_test/20014/console, because we’re trying to link against all .a files found in the llvm-build/lib directory. Let’s be more specific in what we link against. This patch applies a regexp to only use “libclang.*”, “libLLVM.*” and not “libclang_rt.*” static archives. Change by Kuba Mracek (formerly Kuba Brecka) See review here: https://reviews.llvm.org/D23444 Reviewers: tfiala, compnerd llvm-svn: 278527
* Add a few more needed bits to the scripted thread plans.Jim Ingham2016-08-052-0/+6
| | | | llvm-svn: 277879
* Add LLVM build config for BuildAndIntegration.Stephane Sezer2016-07-121-0/+4
| | | | | | | | | | Reviewers: tfiala, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D22234 llvm-svn: 275140
* Apply local patches when building llvm on Mac.Stephane Sezer2016-07-121-0/+8
| | | | | | | | | | | | | | | Summary: This is already done when building for linux with the CMake build system. This functionality disappeared recently when some of the build scripts used by the xcode build system changed. Reviewers: tfiala, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D22233 llvm-svn: 275134
* Add an API to unwind from a hand-called expression.Jim Ingham2016-07-081-0/+8
| | | | | | | This is just an SB API way of doing "thread return -x". <rdar://problem/27110360> llvm-svn: 274822
* Implement GetMemoryRegions() for Linux and Mac OSX core files.Howard Hellyer2016-07-071-0/+3
| | | | | | | | | | | | | | | Summary: This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565 The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo &region_info). Reviewers: clayborg Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D21751 llvm-svn: 274741
* Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, ↵Enrico Granata2016-07-061-0/+23
| | | | | | | | | | | | | | | | synthetic children caching is a tricky area: - if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop; - but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval) Fixes rdar://26480007 llvm-svn: 274683
* Fix "lldb.SBProcess.is_stopped" and "lldb.SBProcess.is_running" to do the ↵Greg Clayton2016-07-051-3/+3
| | | | | | | | right thing. https://llvm.org/bugs/show_bug.cgi?id=28428 llvm-svn: 274568
* fixits are apparently called fix-its.Jim Ingham2016-06-281-2/+2
| | | | | | <rdar://problem/26998596> llvm-svn: 273979
* Add .i files for SBMemoryRegionInfo and SBMemoryRegionInfoList and also hook ↵Greg Clayton2016-06-245-0/+119
| | | | | | | | 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
* Look for CMake.app when searching for cmakeTodd Fiala2016-05-161-0/+18
| | | | | | | | | | | | | | On OS X systems, look for /Applications/CMake.app and ~/Applications/CMake.app versions of the cmake command line binary when trying harder to find a cmake not on the system path. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20303 llvm-svn: 269713
* Add CMake bits necessary for standalone buildKamil Rytarowski2016-05-121-0/+2
| | | | | | | | | | | | Summary: Developed on NetBSD with pkgsrc. Reviewers: zturner, labath Subscribers: jevinskie, zturner, tfiala, Eugene.Zelenko, artagnon, joerg, lldb-commits Differential Revision: http://reviews.llvm.org/D15067 llvm-svn: 269332
* Add the ability to limit "source regexp" breakpoints to a particular functionJim Ingham2016-04-281-0/+6
| | | | | | | | | | | | within a source file. This isn't done, I need to make the name match smarter (right now it requires an exact match which is annoying for methods of a class in a namespace. Also, though we use it in tests all over the place, it doesn't look like we have a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch. llvm-svn: 267834
* Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is usedFrancis Ricci2016-04-252-9/+44
| | | | | | | | | | | | | | | | 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 a build-llvm.py crasher when we can't find cmake. Now it exits with a ↵Greg Clayton2016-04-221-1/+1
| | | | | | valid error that explains what went wrong. llvm-svn: 267235
* 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
* Add missing swig wrappers for r264662Pavel Labath2016-03-291-0/+5
| | | | llvm-svn: 264713
* Fix FILE * leak in Python APIStephane Sezer2016-03-251-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a leak introduced by some of these changes: r257644 r250530 r250525 The changes made in these patches result in leaking the FILE* passed to SetImmediateOutputFile. GetStream() will dup() the fd held by the python caller and create a new FILE*. It will then pass this FILE* to SetImmediateOutputFile, which always uses the flag transfer_ownership=false when it creates a File from the FILE*. Since transfer_ownership is false, the lldb File destructor will not close the underlying FILE*. Because this FILE* came from a dup-ed fd, it will also not be closed when the python caller closes its file. Leaking the FILE* causes issues if the same file is used multiple times by different python callers during the same lldb run, even if these callers open and close the python file properly, as you can end up with issues due to multiple buffered writes to the same file. Reviewers: granata.enrico, zturner, clayborg Subscribers: zturner, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18459 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 264476
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-251-0/+9
| | | | | | | | | | | | | | | "." for "->".) This feature is controlled by an expression command option, a target property and the SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions, those you have to get right when you make them. This is just a first stage. At present the fixits are applied silently. The next step is to tell the user about the applied fixit. <rdar://problem/25351938> llvm-svn: 264379
* Add ThreadSanitizer debugging support.Kuba Brecka2016-03-231-0/+9
| | | | | | | | | | | | This patch adds ThreadSanitizer support into LLDB: - Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented. - A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo. - SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection. - Added some test cases. Reviewed by Greg Clayton. llvm-svn: 264162
* 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-113-2/+9
| | | | | | | | | | | | | | | | | | | | | | | 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
* Add an "offset" option to "break set -n" and "break set -f -l". Jim Ingham2016-03-091-2/+46
| | | | | | | | | | | | That way you can set offset breakpoints that will move as the function they are contained in moves (which address breakpoints can't do...) I don't align the new address to instruction boundaries yet, so you have to get this right yourself for now. <rdar://problem/13365575> llvm-svn: 263049
* Use shallow clones in build-llvm.py.Stephane Sezer2016-03-021-1/+1
| | | | | | | | | | | | | | Summary: This makes cloning (and therefore the whole build) faster. The checkout step goes from ~4m to ~30s on my host. Reviewers: tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17425 llvm-svn: 262513
* This patch stops lldb from loading a .lldbinit file from the currentJason Molenda2016-02-192-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | working directory by default -- a typical security problem that we need to be more conservative about. It adds a new target setting, target.load-cwd-lldbinit which may be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit) or warn (warn if there is a $cwd/.lldbinit and don't read it). The default is set to warn. If this is met with unhappiness, we can look at changing the default to true (to match current behavior) on a different platform. This does not affect reading of ~/.lldbinit - that will still be read, as before. If you run lldb in your home directory, it will not warn about the presence of a .lldbinit file there. I had to add two SB API - SBHostOS::GetUserHomeDirectory and SBFileSpec::AppendPathComponent - for the lldb driver code to be able to get the home directory path in an OS neutral manner. The warning text is There is a .lldbinit file in the current directory which is not being read. To silence this warning without sourcing in the local .lldbinit, add the following to the lldbinit file in your home directory: settings set target.load-cwd-lldbinit false To allow lldb to source .lldbinit files in the current working directory, set the value of this variable to true. Only do so if you understand and accept the security risk. <rdar://problem/24199163> llvm-svn: 261280
* Adding an SBThread::StepInto that takes an end-line, also moved the code ↵Jim Ingham2016-02-131-0/+11
| | | | | | | | that figures out the address range for the step to SymbolContext. llvm-svn: 260772
* 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
* Add a note on how to create an empty target and use it to attach toJim Ingham2016-02-011-0/+10
| | | | | | processes whose executables you don't know up front. llvm-svn: 259396
* Remove autoconf support from source directories.Eugene Zelenko2016-01-284-152/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* modify Xcode build to use cmake/ninja for internal llvm/clangTodd Fiala2016-01-284-408/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change restores the Xcode build to working after Makefile support was stripped from LLVM and clang recently. With this change, the Xcode build now requires cmake (2.8.12.2+). The cmake must either be on the path that Xcode sees, or it must exist in one of the following locations: * /usr/local/bin/cmake * /opt/local/bin/cmake * $HOME/bin/cmake If the ninja build tool is present on the path, it will be used. If not, ninja will be cloned (via git), bootstrap-built, and used for the llvm/clang build. LLDB now requires a minimum deployment target of OS X 10.9. Prior to this, it was 10.8. The llvm/clang cmake build will not run with Xcode 7.2 or Xcode 7.3 beta's compiler with the minimum deployment target set to anything lower than 10.9. This is related to #include <atomic>. When llvm or clang source code does not exist in the lldb tree, it will be cloned via git using http://llvm.org/git/{project}.git. Previously it used SVN. If this causes any heartache, we can make this smarter, autodetect an embedded svn and use svn instead. (And/or use SVN if a git command is not available). This change also fixes an lldb-mi linkage failure (needed libncurses) as exposed by one of the LLVM libs. llvm-svn: 259027
* [LLDB][MIPS] A small fix in GetBreakableLoadAddress() for MIPSBhushan D. Attarde2016-01-271-0/+3
| | | | | | | | | | | | | SUMMARY: Get the load address for the address given by symbol and function. Earlier, this was done for function only, this patch does it for symbol too. This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change. Reviewers: clayborg Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits Differential Revision: http://reviews.llvm.org/D16049 llvm-svn: 258919
* Fix some issues with bytes and strings in Python 3.Zachary Turner2016-01-252-4/+9
| | | | | | | | | | | | | | | | | | 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
* Fix more occurrences of string/bytes/bytearray in swig typemaps.Zachary Turner2016-01-251-20/+44
| | | | llvm-svn: 258742
* Fix swig typemap for SBEvent.Zachary Turner2016-01-251-6/+14
| | | | | | | | | | | This needs to be able to handle bytes, strings, and bytearray objects. In Python 2 this was easy because bytes and strings are the same thing, but in Python 3 the 2 cases need to be handled separately. So as not to mix raw Python C API code with PythonDataObjects code, I've also introduced a PythonByteArray class to PythonDataObjects to make the paradigm used here consistent. llvm-svn: 258741
* Fix ResourceWarning about unclosed file in use_lldb_suite_root.py.Zachary Turner2016-01-152-6/+12
| | | | llvm-svn: 257945
* Get rid of const char** typemaps.Zachary Turner2016-01-131-70/+7
| | | | | | | | We already have char** typemaps which were near copy-pastes of the const char** versions. This way we have only one version that works for both. llvm-svn: 257670
* Fix TestProcessLaunch for Python 3.Zachary Turner2016-01-131-21/+29
| | | | | | | | | | | | | | | | | | There were a number of problems preventing this from working: 1. The SWIG typemaps for converting Python lists to and from C++ arrays were not updated for Python 3. So they were doing things like PyString_Check instead of using the PythonString from PythonDataObjects. 2. ProcessLauncherWindows was ignoring the environment completely. So any test that involved launching an inferior with any kind of environment variable would have failed. 3. The test itself was using process.GetSTDOUT(), which isn't implemented on Windows. So this was changed to save the value of the environment variable in a local variable and have the debugger look at the value of the variable. llvm-svn: 257669
* Fix an issue where scripted commands would not actually print any of their ↵Enrico Granata2016-01-131-1/+3
| | | | | | | | output if an immediate output file was set in the result object via a Python file object Fixes rdar://24130303 llvm-svn: 257644
* Fix Python 3 issues related to OS plugins.Zachary Turner2016-01-111-9/+11
| | | | | | | | | | * lldb::tid_t was being converted incorrectly, so this is updated to use PythonInteger instead of manual Python Native API calls. * OSPlugin_RegisterContextData was assuming that the result of get_register_data was a string, when in fact it is a bytes. So this method is updated to use PythonBytes to do the work. llvm-svn: 257398
OpenPOWER on IntegriCloud