summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/interface
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/Bindings] Move bindings into their own subdirectoryJonas Devlieghere2020-01-0966-10918/+0
| | | | | | | | | | | | All the code required to generate the language bindings for Python and Lua lives under scripts, even though the majority of this code aren't scripts at all, and surrounded by scripts that are totally unrelated. I've reorganized these files and moved everything related to the language bindings into a new top-level directory named bindings. This makes the corresponding files self contained and much more discoverable. Differential revision: https://reviews.llvm.org/D72437
* [lldb/SWIG] Refactor extensions to be non Python-specific (3/3)Jonas Devlieghere2020-01-0817-0/+55
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. It uses a SWIG macro to reduce code duplication. Differential revision: https://reviews.llvm.org/D72377
* [lldb/SWIG] Refactor extensions to be non Python-specific (2/2)Jonas Devlieghere2020-01-0821-15/+39
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. It uses a SWIG macro to reduce code duplication. Differential revision: https://reviews.llvm.org/D72377
* [lldb/SWIG] Refactor extensions to be non Python-specificJonas Devlieghere2020-01-081-1/+16
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. Differential revision: https://reviews.llvm.org/D72377
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-111-3/+0
| | | | | | | | This is a half-implemented feature that as far as we can tell was never used by anything since its original inclusion in 2014. This patch removes it to make remaining the code easier to understand. Differential Revision: https://reviews.llvm.org/D71310
* [lldb/SWIG] Guard Python type map in SWIG interface by SWIGPYTHONJonas Devlieghere2019-12-091-5/+2
| | | | | | Guard the Python type map in SBTarget by the SWIGPYTHON define to ensures the rest of the interface can be reused for other languages supported by SWIG.
* [lldb/SWIG] Guard embedded Python code in SWIG interfaces by SWIGPYTHONJonas Devlieghere2019-12-0836-0/+82
| | | | | | Guard the embedded Python code in LLDB's interface files by the SWIGPYTHON define to ensures they can be reused for other languages supported by SWIG.
* Add the ability to pass extra args to a Python breakpoint callback.Jim Ingham2019-10-253-1/+22
| | | | | | | | | | | | | | | | | For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no way to write a generic "stop when my caller is..." function, and then specify the caller when you add the command to a breakpoint. With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right signature) when the breakpoint is hit. Then in lldb, you can say: (lldb) break com add -F caller_is -k caller_name -v Foo More generally this will allow us to write reusable Python breakpoint commands. Differential Revision: https://reviews.llvm.org/D68671
* remove FILE* usage from SBStream.iLawrence D'Anna2019-10-151-1/+12
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes FILE* and replaces it with SBFile and FileSP the SWIG interface for `SBStream.i`. And this is the last one. With this change, nothing in the python API will can access a FILE* method on the C++ side. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68960 llvm-svn: 374924
* convert SBDebugger::***FileHandle() wrappers to native files.Lawrence D'Anna2019-10-151-18/+33
| | | | | | | | | | | | | | | | | | | | Summary: This patch converts the swig wrappers for SetInputFileHandle() and friends to emulate the old behavior using SetInputFile(). This will clear the way for deleting the FILE* typemaps altogether. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mehdi_amini, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68856 llvm-svn: 374912
* SBFile::GetFile: convert SBFile back into python native files.Lawrence D'Anna2019-10-151-0/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: This makes SBFile::GetFile public and adds a SWIG typemap to convert the result back into a python native file. If the underlying File itself came from a python file, it is returned identically. Otherwise a new python file object is created using the file descriptor. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68737 llvm-svn: 374911
* remove FILE* bindings from SBInstruction.Lawrence D'Anna2019-10-142-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch replaces the FILE* python bindings for SBInstruction and SBInstructionList and replaces them with the new, safe SBFile and FileSP bindings. I also re-enable `Test_Disassemble_VST1_64`, because now we can use the file bindings as an additional test of the disassembler, and we can use the disassembler test as a test of the file bindings. The bugs referred to in the comments appear to have been fixed. The radar is closed now and the bugzilla bug does not reproduce with the instructions given. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68890 llvm-svn: 374820
* remove FILE* usage from ReportEventState() and HandleProcessEvent()Lawrence D'Anna2019-10-142-3/+12
| | | | | | | | | | | | | | | | | | | Summary: This patch adds FileSP and SBFile versions of the API methods ReportEventState and HandleProcessEvent. It points the SWIG wrappers at these instead of the ones that use FILE* streams. Reviewers: JDevlieghere, jasonmolenda, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68546 llvm-svn: 374816
* update SBDebugger::SetInputFile() etc to work on native FilesLawrence D'Anna2019-10-101-0/+15
| | | | | | | | | | | | | | | | | | | Summary: This patch adds FileSP versions of SetInputFile(), SetOutputFile, and SetErrorFile(). SWIG will convert native python file objects into FileSP. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: clayborg, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68734 llvm-svn: 374422
* SBFile support in SBCommandReturnObjectLawrence D'Anna2019-10-091-8/+19
| | | | | | | | | | | | | | | | | | Summary: This patch add SBFile interfaces to SBCommandReturnObject, and removes the internal callers of its FILE* interfaces. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68434 llvm-svn: 374238
* allow arbitrary python streams to be converted to SBFileLawrence D'Anna2019-10-091-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds SWIG typemaps that can convert arbitrary python file objects into lldb_private::File. A SBFile may be initialized from a python file using the constructor. There are also alternate, tagged constructors that allow python files to be borrowed, and for the caller to control whether or not the python I/O methods will be called even when a file descriptor is available.I Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: zturner, amccarth, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68188 llvm-svn: 374225
* Pass an SBStructuredData to scripted ThreadPlans on use.Jim Ingham2019-10-032-0/+13
| | | | | | | | | | This will allow us to write reusable scripted ThreadPlans, since you can use key/value pairs with known keys in the plan to parametrize its behavior. Differential Revision: https://reviews.llvm.org/D68366 llvm-svn: 373675
* SBDebugger::SetInputFile, SetOutputFile, etc.Lawrence D'Anna2019-10-031-0/+18
| | | | | | | | | | | | | | | | | | | | | Summary: Add new methods to SBDebugger to set IO files as SBFiles instead of as FILE* streams. In future commits, the FILE* methods will be deprecated and these will become the primary way to set the debugger I/O streams. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68181 llvm-svn: 373563
* new api class: SBFileLawrence D'Anna2019-10-031-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SBFile is a scripting API wrapper for lldb_private::File This is the first step in a project to enable arbitrary python io.IOBase file objects -- including those that override the read() and write() methods -- to be used as the main debugger IOStreams. Currently this is impossible because python file objects must first be converted into FILE* streams by SWIG in order to be passed into the debugger. full prototype: https://github.com/smoofra/llvm-project/tree/files Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67793 llvm-svn: 373562
* Fix some swig warningsPavel Labath2019-09-275-21/+3
| | | | | | | | | Previously, these were unseen because the wrapper script would swallow them. This fixes the following types of warnings: - methods being declared more than once - swig complained about ignoring operator=, so I just removed it llvm-svn: 373069
* Revert "[swig] Add workaround for old swig"Jonas Devlieghere2019-07-161-5/+0
| | | | | | | With the deprecation of swig 1.x (r366213), this workaround should no longer be necessary. llvm-svn: 366221
* [swig] Add workaround for old swigJonas Devlieghere2019-07-111-0/+5
| | | | | | | | | Apparently, when using swig 1.3.40, properties to set values do not work without the `__swig_setmethods__` workaround. I conditionally added this back for SBTypeCategory, as it's causing a test failure on GreenDragon, while I investigate this further. llvm-svn: 365718
* [swig] Don't mess with swig internals.Jonas Devlieghere2019-07-0231-842/+287
| | | | | | | | | | | | | | | As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no longer defined. It appears that there's no need to mess with these internals, we can simplify define the corresponding properties inline. Originally I wanted to use the swig extension %attribute and %attributeref to define properties. However, I couldn't find a way to add documentation to these attributes. Since we already had the properties defined inline, we might as well keep them. Differential revision: https://reviews.llvm.org/D63530 llvm-svn: 364974
* Revert "[swig] Define attribute(ref) instead of accessing swig internals."Jonas Devlieghere2019-07-0210-114/+289
| | | | | | This reverts commit f9b91a52797325ccaaee229e414beae7c03f1948. llvm-svn: 364951
* [swig] Define attribute(ref) instead of accessing swig internals.Jonas Devlieghere2019-07-0210-289/+114
| | | | | | | | | | | As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no longer defined. The solution is to stop using these internal swig dictionaries and use %attribute and %attributeref instead. I plan on doing this incrementally, with this differential serving as an example. Differential revision: https://reviews.llvm.org/D63530 llvm-svn: 364946
* Make SBDebugger.RunCommandInterpreter callable from Python.Jim Ingham2019-05-151-0/+26
| | | | | | | | Authored by: Lukas Boger Differential Revision: https://reviews.llvm.org/D61602 llvm-svn: 360730
* modify-python-lldb: Remove \a-removing codePavel Labath2019-04-234-19/+19
| | | | | | instead, remove \a directly from the interface files. llvm-svn: 358967
* modify-python-lldb.py: Remove docstring formatting codePavel Labath2019-04-212-64/+59
| | | | | | | | | | | The strings have been already cleaned up in r358683, so this code is not doing anything anymore. While comparing the outputs before and after removing the formatting code, I've found a couple of docstrings that managed to escape my perl script in r358683, so I format them manually with this patch. llvm-svn: 358846
* Clean up docstrings in swig interface filesPavel Labath2019-04-1855-1824/+1563
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes the "//----" frames and "///" leading lines from docstring comments. We already have code doing transformations like this in modify-python-lldb.py, but that's a script I'd like to remove. Instead of running these transformations everytime we run swig, we can just perform equivalent on its input once. This patch can be reproduced (e.g. for downstream merges) with the following "sweet" perl command: perl -i -p -e 'BEGIN{ $/ = undef;} s:(" *\n) *//-----*\n:\1:gs; s:^( *)/// ?:\1:gsm; s:^ *//------*\n( *\n)?( *"):\2:gsm; s: *$::gsm; s:\n *"\):"):gsm' scripts/interface/*.i This command produces nearly equivalent python files to those produced by the relevant code in modify-python-lldb.py. The only difference I noticed is that here I am slightly more agressive in removing trailing newlines from docstring comments (the python script seems to leave newlines in class-level docstrings). Reviewers: amccarth, clayborg, jingham, aprantl Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60498 llvm-svn: 358683
* Docstringify some comments in the swig interface filesPavel Labath2019-04-103-4/+8
| | | | | | Without these, the comments don't end up in the generated python code. llvm-svn: 358055
* Remove unneeded #ifdef SWIGsPavel Labath2019-04-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some of these were present in files which should never be read by swig (and we also had one in the interface file, which is only read by swig). They are probably leftovers from the time when we were running swig over lldb headers directly. While writing this patch, I noticed that some of the #ifdefs were guarding public functions that were operating on lldb_private data types. While it wasn't strictly necessary for this patch, I made these private, as nobody should really be accessing them. This can potentially break existing code if it happened to use these methods, though it will only break at build time -- if someone builds against an old header, he should still be able to link to a new lldb library, since the functions are still there. We could keep these public for backward compatbility, but I would argue that if anyone was actually using these functions for anything, his code is already broken. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60400 llvm-svn: 357984
* modify-python-lldb.py: (Re)move __len__ and __iter__ supportPavel Labath2019-04-041-0/+23
| | | | | | | | | | | | | | | | 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-0313-1/+113
| | | | | | | | | | | | | | | | | | | | | | | 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-025-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix/unify SBType comparisonPavel Labath2019-03-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1155-0/+122
| | | | | | | | | | | | | | | | | | | | | | | 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-272-0/+78
| | | | | | | | | | | | | | | | | | | 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
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-212-25/+2
| | | | | | | | | | | | | | | | As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1966-264/+198
| | | | | | | | | | | | | | | | | 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
* [lldb] Add a "display-recognized-arguments" target setting to show ↵Kuba Mracek2018-12-201-1/+1
| | | | | | | | recognized arguments by default Differential Revision: https://reviews.llvm.org/D55954 llvm-svn: 349856
* Overload GetMemoryRegions for the ProcessMinidumpTatyana Krasnukha2018-12-201-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D55841 llvm-svn: 349767
* [lldb] Retrieve currently handled Obj-C exception via ↵Kuba Mracek2018-12-201-0/+18
| | | | | | | | | | | | __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object. The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace. Differential Revision: https://reviews.llvm.org/D44072 llvm-svn: 349718
* [Reproducers] Change how reproducers are initialized.Jonas Devlieghere2018-12-032-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the way the reproducer is initialized. Rather than making changes at run time we now do everything at initialization time. To make this happen we had to introduce initializer options and their SB variant. This allows us to tell the initializer that we're running in reproducer capture/replay mode. Because of this change we also had to alter our testing strategy. We cannot reinitialize LLDB when using the dotest infrastructure. Instead we use lit and invoke two instances of the driver. Another consequence is that we can no longer enable capture or replay through commands. This was bound to go away form the beginning, but I had something in mind where you could enable/disable specific providers. However this seems like it adds very little value right now so the corresponding commands were removed. Finally this change also means you now have to control this through the driver, for which I replaced --reproducer with --capture and --replay to differentiate between the two modes. Differential revision: https://reviews.llvm.org/D55038 llvm-svn: 348152
* [Target] Do not skip a stop on a breakpoint if a plan was completedAleksandr Urakov2018-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes the next situation. On Windows clang-cl makes no stub before the main function, so the main function is located exactly on module entry point. May be it is the same on other platforms. So consider the following sequence: - set a breakpoint on main and stop there; - try to evaluate expression, which requires a code execution on the debuggee side. Such an execution always returns to the module entry, and the plan waits for it there; - the plan understands that it is complete now and removes its breakpoint. But the breakpoint site is still there, because we also have a breakpoint on entry; - StopInfo analyzes a situation. It sees that we have stopped on the breakpoint site, and it sees that the breakpoint site has owners, and no one logical breakpoint is internal (because the plan is already completed and it have removed its breakpoint); - StopInfo thinks that it's a user breakpoint and skips it to avoid recursive computations; - the program continues. So in this situation the program continues without a stop right after the expression evaluation. To avoid this an additional check that the plan was completed was added. Reviewers: jingham, zturner, boris.ulasevich Reviewed by: jingham Tags: #lldb Differential Revision: https://reviews.llvm.org/D53761 llvm-svn: 347974
* [Reproducers] Improve reproducer API and add unit tests.Jonas Devlieghere2018-11-271-2/+2
| | | | | | | | | | | | | | | | | | | When I landed the initial reproducer framework I knew there were some things that needed improvement. Rather than bundling it with a patch that adds more functionality I split it off into this patch. I also think the API is stable enough to add unit testing, which is included in this patch as well. Other improvements include: - Refactor how we initialize the loader and generator. - Improve naming consistency: capture and replay seems the least ambiguous. - Index providers by name and make sure there's only one of each. - Add convenience methods for creating and accessing providers. Differential revision: https://reviews.llvm.org/D54616 llvm-svn: 347716
* Add setting to require hardware breakpoints.Jonas Devlieghere2018-11-151-0/+3
| | | | | | | | | | | | | | | | When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`. However, there's no option to force LLDB to use hardware breakpoints internally, for example while stepping. This patch adds a setting target.require-hardware-breakpoint that forces LLDB to always use hardware breakpoints. Because hardware breakpoints are a limited resource and can fail to resolve, this patch also extends error handling in thread plans, where breakpoints are used for stepping. Differential revision: https://reviews.llvm.org/D54221 llvm-svn: 346920
* Add GDB remote packet reproducer.Jonas Devlieghere2018-11-131-24/+30
| | | | llvm-svn: 346780
* Add an SBExpressionOptions setting mirroring the "exec" command's --allow-jit.Jim Ingham2018-11-021-0/+8
| | | | | | | | <rdar://problem/44809176> Differential Revision: https://reviews.llvm.org/D54056 llvm-svn: 346053
* [lldb] Introduce StackFrameRecognizer [take 3]Kuba Mracek2018-10-311-1/+7
| | | | | | | | 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
OpenPOWER on IntegriCloud