summaryrefslogtreecommitdiffstats
path: root/lldb/source/API
Commit message (Collapse)AuthorAgeFilesLines
...
* [SystemInitializerFull] Fix header sorting (NFC)Jonas Devlieghere2019-04-241-2/+1
| | | | | | Made some changes downstream that touched the header sorting. llvm-svn: 359141
* [CMake] Emit LLDB.framework.dSYM to avoid potential name collision with ↵Stefan Granitz2019-04-181-0/+4
| | | | | | | | | | | | | | | | | | driver's lldb.dSYM Summary: Emit framework's dSYM bundle as LLDB.framework.dSYM instead of LLDB.dSYM, because the latter could conflict with the driver's lldb.dSYM when emitted in the same directory on case-insensitive file systems. Requires https://reviews.llvm.org/D60862 Reviewers: friss, beanz, bogner Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D60863 llvm-svn: 358686
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-109-40/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Remove unneeded #ifdef SWIGsPavel Labath2019-04-092-20/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Get the run locker before you ask if your thread is valid.Jim Ingham2019-04-091-3/+3
| | | | | | | | | | | | | | | I have occasional crashes coming from SBThread::GetExtendedBacktraceThread. The symptom is that we got true back from HasThreadScope - so we should have a valid live thread, but then when we go to use the thread, it is not good anymore and we crash. I can't spot any obvious cause for this crash, but in looking for same I noticed that in the current code we check that the thread is valid, THEN we take the stop locker. We really should do that in the other order, and ensure that the process will stay stopped before we check our thread is still good. That's what this patch does. <rdar://problem/47478205> llvm-svn: 357963
* Rename Target::GetSharedModule to Target::GetOrCreateModule.Jason Molenda2019-04-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the caller must call ModulesDidLoad after adding all the new modules, but postponing this notification until they're all batched up can allow for better efficiency than notifying one-by-one. Change the name of the ModuleList notifier functions that a subclass can implement to start with 'Notify' to make it clear what they are. Add a NotifyModulesRemoved. Add header documentation for the changed/updated methods. Added defaulted-value 'notify' argument to ModuleList Append, AppendIfNeeded, and Remove because callers working with a local ModuleList don't have an obvious idea of what notify means in this context. When the ModuleList is a part of the Target class, the notify behavior matters. DynamicLoaderDarwin has been updated so that libraries being added/removed are correctly batched up before notifications are sent. Added the TestModuleLoadedNotifys.py test to run on Darwin to test this. <rdar://problem/48293064> Differential Revision: https://reviews.llvm.org/D60172 llvm-svn: 357955
* [Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere2019-04-0356-75/+74
| | | | | | | | | | | | | | | For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not. This patch adds the missing macros and updates the lldb-instr tool. Differential revision: https://reviews.llvm.org/D60178 llvm-svn: 357639
* Make operator==s consistent between c++ and python APIsPavel Labath2019-04-023-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Python include from ScriptInterpreterPython.hJonas Devlieghere2019-03-292-8/+0
| | | | | | | | | | | This patch limits the scope of the python header to the implementation of the python script interpreter plugin. ScriptInterpreterPython is now an abstract interface that doesn't expose any Python specific types, and is implemented by the ScriptInterpreterPythonImpl. Differential revision: https://reviews.llvm.org/D59976 llvm-svn: 357307
* [Platform] Remove Kalimba PlatformJonas Devlieghere2019-03-271-3/+0
| | | | | | | | | This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
* [Python] Remove dynamic indirectionJonas Devlieghere2019-03-262-4/+0
| | | | | | | Now that the Python plugin relies on the SWIG symbols, we no longer need to dynamically resolve these functions. llvm-svn: 357034
* [Python] Define empty SWIG wrapper for unit testin"Jonas Devlieghere2019-03-261-0/+5
| | | | | | | | | The python plugin uses wrappers generated by swig. For the symbols to be available, we'd need to link against liblldb, which is not an option because the symbols could conflict with the static library we are testing. Instead we define the symbols ourselves in the unit test. llvm-svn: 356971
* [Python] Move SWIG wrapper dependency into the pluginJonas Devlieghere2019-03-251-5/+0
| | | | | | This should fix the Windows bot (fingers crossed). llvm-svn: 356967
* [ScriptInterpreterPython] Move SWIG initialization into the Python plugin (NFC)Jonas Devlieghere2019-03-251-169/+1
| | | | | | Abstract initialization of the Python SWIG support in the Python plugin. llvm-svn: 356942
* [lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny2019-03-1967-2900/+3513
| | | | | | | | | | | | Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB. Differential Revision: https://reviews.llvm.org/D59427 llvm-svn: 356481
* [API] Remove unneded LLDB_DISABLE_PYTHON markers.Davide Italiano2019-03-187-45/+0
| | | | llvm-svn: 356401
* Fix some "variable 'foo' set but not used" warningsPavel Labath2019-03-182-6/+2
| | | | | | gcc-8 diagnoses these. llvm-svn: 356378
* [Reproducers] Support capturing a reproducer without an explicit path.Jonas Devlieghere2019-03-121-0/+9
| | | | | | | | | | | | | | Tablegen doesn't support options that are both flags and take values as an argument. I noticed this when doing the tablegen rewrite, but forgot that that affected the reproducer --capture flag. This patch makes --capture a flag and adds --capture-path to specify a path for the reproducer. In reality I expect this to be mostly used for testing, but it could be useful nonetheless. Differential revision: https://reviews.llvm.org/D59238 llvm-svn: 355936
* [Reproducers] Implement log_append for function pointers.Jonas Devlieghere2019-03-113-10/+13
| | | | | | | | | | Changing the type in the DUMMY macro to void* doesn't actually fix the build error, because the argument type is deducted from the template (as opposed to when serializing through the instrumentation framework, where this would matter). Instead I've added a proper instance of log_append that takes function pointers and logs their address. llvm-svn: 355863
* [Reproducers] Replace callbacks with void*Jonas Devlieghere2019-03-113-13/+10
| | | | | | | | Callbacks in the LLDB_RECORD_DUMMY macros were causing build failures with the Xcode project. This patch replaces the function pointers with void pointers so they can be logged. llvm-svn: 355842
* Add "operator bool" to SB APIsPavel Labath2019-03-1156-0/+305
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Reproducers] Add missing LLDB_RECORD_DUMMY macrosJonas Devlieghere2019-03-0811-7/+105
| | | | | | | Re-ran lldb-inst on the API folder to insert missing LLDB_RECORD_DUMMY macros. llvm-svn: 355711
* [Reproducers] Add LLDB_RECORD_DUMMYJonas Devlieghere2019-03-081-3/+6
| | | | | | | | | | | | | Add a macro that doesn't actually record anything but still toggles the API boundary. Removing just the register macros for lldb::thread_t wasn't sufficient on NetBSD because the serialization logic needed the underlying type to be complete. This macro should be used by functions that are currently unsupported, as they might trip the API boundary logic. This should be easy using the lldb-instr tool. llvm-svn: 355709
* [SBAPI] Log from record macroJonas Devlieghere2019-03-0738-3024/+75
| | | | | | | | | | | | | | | | The current record macros already log the function being called. This patch extends the macros to also log their input arguments and removes explicit logging from the SB API. This might degrade the amount of information in some cases (because of smarter casts or efforts to log return values). However I think this is outweighed by the increased coverage and consistency. Furthermore, using the reproducer infrastructure, diagnosing bugs in the API layer should become much easier compared to relying on log messages. Differential revision: https://reviews.llvm.org/D59101 llvm-svn: 355649
* [Reproducers] Disable registering lldb::thread_t everywhereJonas Devlieghere2019-03-071-11/+0
| | | | | | | | | As discussed on the mailing list, default serialization for thread ids is not correct, even if they're represented as basic types. I'm purposely leaving the corresponding record macros in place so that we don't break the API boundary detection. llvm-svn: 355610
* Repair the build when LLDB_DISABLE_PYTHON is setAlex Langford2019-03-071-20/+28
| | | | | | | | | | | Summary: If LLDB_DISABLE_PYTHON is set, some functions are unavailable but SBReproducer assumes they are. Let's conditionally register those functions since they are conditionally declared. Differential Revision: https://reviews.llvm.org/D59056 llvm-svn: 355575
* Pass /bigobj for SBReproducer.cpp with MSVCZachary Turner2019-03-061-0/+4
| | | | | | | | | /BIGOBJ is used to bypass certain COFF file format limitations and is used with, unsurprisingly, very big object files. This file has grown large enough that it needs this flag in order to compile successfully. llvm-svn: 355559
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-1/+1
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* [Reproducers] Guard register macros that take lldb::thread_t on WindowsJonas Devlieghere2019-03-061-0/+4
| | | | | | | | On Windows, lldb::thread_t is just a void*, so the we will try to allocate an object of type void when deserializing. Undef this for now until we support void* arguments. llvm-svn: 355519
* [Reproducers] Don't use VLA in SBReproducer redirectJonas Devlieghere2019-03-061-1/+1
| | | | | | This should unbreak the Windows bot. llvm-svn: 355518
* Re-commit logging for SBCompileUnit::GetNumLineEntries.Jason Molenda2019-03-061-1/+7
| | | | llvm-svn: 355473
* [Reproducers] Enable replay from SBRepro.Jonas Devlieghere2019-03-061-3/+0
| | | | | | | | | Now that the LLDB instrumentation macros are in place, we should use that to test reproducer replay. Differential revision: https://reviews.llvm.org/D58565 llvm-svn: 355470
* [Reproducers] Don't intercept SBDebugger::SetInputFileHandleJonas Devlieghere2019-03-061-3/+1
| | | | | | | With the reproducer logic in place for the command interpreter we no longer need to make SBDebugger::SetInputFileHandle a no-op. llvm-svn: 355469
* [Reproducers] Add SBReproducer macrosJonas Devlieghere2019-03-0666-983/+8842
| | | | | | | | | | This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API source files. Differential revision: https://reviews.llvm.org/D57475 llvm-svn: 355459
* [SBAPI] Don't check IsValid in constructorJonas Devlieghere2019-03-0620-150/+136
| | | | | | | | | | | | | | | | | | | | | | | When running the test suite with the instrumentation macros, I noticed two lldb-mi tests regressed. The issue was the copy constructor of SBLineEntry. Without the macros the returned value would be elided, but with the macros the copy constructor was called. The latter using ::IsValid to determine whether the underlying opaque pointer should be set. This is likely a remnant of when ::IsValid would only check the validity of the smart pointer. In SBLineEntry however, it actually forwards to LineEntry::IsValid(). So what happened here was that because of the macros the copy constructor was called. The opaque pointer was valid but the LineEntry didn't consider itself valid. So the copied-to object ended up default initialized. This patch replaces all checks for IsValid in copy (assignment) constructors with checks for the opaque pointer itself. Differential revision: https://reviews.llvm.org/D58946 llvm-svn: 355458
* Revert logging addition to SBCompileUnit::GetNumLineEntries,Jason Molenda2019-03-051-6/+1
| | | | | | causing lldb-mi testsuite failures? llvm-svn: 355449
* Add logging to SBCompileUnit::GetNumLineEntries.Jason Molenda2019-03-051-1/+6
| | | | llvm-svn: 355435
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-043-1/+3
| | | | | | | | | | | | | | | | | | | | | There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist. To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being. After this there is only 2 remaining references to Target from Host, which I'll address in a followup. Differential Revision: https://reviews.llvm.org/D58842 llvm-svn: 355342
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
* [Reproducers] Capture and replay interpreter commands.Jonas Devlieghere2019-03-021-2/+51
| | | | | | | | | | | | | | | | | This patch adds the necessary logic to capture and replay commands entered into the command interpreter. A DataRecorder shadows the input and writes its data to a know file. During replay this file is used as the command interpreter's input. It's possible to the command interpreter more than once, with a different input source. We support this scenario by using multiple buffers. The synchronization for this takes place at the SB layer, where we create a new recorder every time the debugger input is changed. During replay we use the corresponding buffer as input. Differential revision: https://reviews.llvm.org/D58564 llvm-svn: 355249
* [CMake] Make liblldb depend on clang-headersAlex Langford2019-02-281-0/+4
| | | | | | | | | | | Summary: The clang headers are useful when dealing with clang modules. There is also a way to get to the clang headers from the SB API so it would be nice if they were also available when we just build lldb. Differential Revision: https://reviews.llvm.org/D58793 llvm-svn: 355149
* [Reprodicuers] Check initializationJonas Devlieghere2019-02-281-0/+4
| | | | | | | If the reproducer is not initialzied, the call to ::Instance() will result in an assertion. llvm-svn: 355055
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-216-64/+35
| | | | | | | | | | | | | | | | 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
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-1325-636/+636
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-1110-34/+54
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Update files to the new header that were incorrectly landed with the oldChandler Carruth2019-02-112-8/+6
| | | | | | one. llvm-svn: 353663
* [Reproducers] SBReproducer framework: Capture & ReplayJonas Devlieghere2019-02-063-0/+124
| | | | | | | | | | | | | This is part two of the reproducer instrumentation framework. It contains the code to capture and replay function calls. The main user of this framework will be the SB API layer. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D56322 llvm-svn: 353324
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to HostPavel Labath2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: These classes describe the details of the process we are about to launch, and so they are naturally used by the launching code in the Host module. Previously they were present in Target because that is the most important (but by far not the only) user of the launching code. Since the launching code has other customers, must of which do not care about Targets, it makes sense to move these classes to the Host layer, next to the launching code. This move reduces the number of times that Target is included from host to 8 (it used to be 14). Reviewers: zturner, clayborg, jingham, davide, teemperor Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56602 llvm-svn: 353047
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1970-280/+210
| | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud