summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/None
AgeCommit message (Collapse)Author
2025-02-12[lldb] Remove Debugger::Get{Output,Error}Stream (NFC) (#126821)Jonas Devlieghere
Remove Debugger::GetOutputStream and Debugger::GetErrorStream in preparation for replacing both with a new variant that needs to be locked and hence can't be handed out like we do right now. The patch replaces most uses with GetAsyncOutputStream and GetAsyncErrorStream respectively. There methods return new StreamSP objects that automatically get flushed on destruction. See #126630 for more details.
2023-11-27[lldb] Improve error message for script commands when there's no interpreter ↵David Spickett
(#73321) It was: ``` error: there is no embedded script interpreter in this mode. ``` 1. What does "mode" mean? 2. It implies there might be an embedded script interpreter for some other "mode", whatever that would be. So I'm simplifying it and noting the most common reason for this which is that lldb wasn't built with a scripting language enabled in the first place. There are other tips for dealing with this, but I'm not sure this message is the best place for them.
2023-08-09[lldb] Sink StreamFile into lldbHostAlex Langford
StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libraries, so I think it makes sense for this to live in lldbHost instead. Differential Revision: https://reviews.llvm.org/D157460
2021-10-28[lldb] Remove ConstString from Process, ScriptInterpreter and StructuredData ↵Pavel Labath
plugin names
2021-10-18[lldb] Return StringRef from PluginInterface::GetPluginNamePavel Labath
There is no reason why this function should be returning a ConstString. While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings. I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is. Differential Revision: https://reviews.llvm.org/D111877
2021-09-13[lldb] Remove PluginInterface::GetPluginVersionPavel Labath
In all these years, we haven't found a use for this function (it has zero callers). Lets just remove the boilerplate. Differential Revision: https://reviews.llvm.org/D109600
2021-07-02[lldb] Replace default bodies of special member functions with = default;Jonas Devlieghere
Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041
2020-08-17[lldb] Get rid of helper CMake variables for PythonJonas Devlieghere
This patch is a big sed to rename the following variables: s/PYTHON_LIBRARIES/Python3_LIBRARIES/g s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g s/PYTHON_RPATH/Python3_RPATH/g I've also renamed the CMake module to better express its purpose and for consistency with FindLuaAndSwig. Differential revision: https://reviews.llvm.org/D85976
2020-02-17[lldb] Update header guards to be consistent and compliant with LLVM (NFC)Jonas Devlieghere
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743
2020-02-14[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)Jonas Devlieghere
Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to avoid name conflict.
2020-02-10[LLDB] Fix GCC warnings about extra semicolons. NFC.Martin Storsjö
2020-02-07[lldb/Plugins] Use external functions to (de)initialize pluginsJonas Devlieghere
This is a step towards making the initialize and terminate calls be generated by CMake, which in turn is towards making it possible to disable plugins at configuration time. Differential revision: https://reviews.llvm.org/D74245
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-09-27remove File::SetStream(), make new files instead.Lawrence D'Anna
Summary: This patch removes File::SetStream() and File::SetDescriptor(), and replaces most direct uses of File with pointers to File. Instead of calling SetStream() on a file, we make a new file and replace it. My ultimate goal here is to introduce a new API class SBFile, which has full support for python io.IOStream file objects. These can redirect read() and write() to python code, so lldb::Files will need a way to dispatch those methods. Additionally it will need some form of sharing and assigning files, as a SBFile will be passed in and assigned to the main IO streams of the debugger. In my prototype patch queue, I make File itself copyable and add a secondary class FileOps to manage the sharing and dispatch. In that case SBFile was a unique_ptr<File>. (here: https://github.com/smoofra/llvm-project/tree/files) However in review, Pavel Labath suggested that it be shared_ptr instead. (here: https://reviews.llvm.org/D67793) In order for SBFile to use shared_ptr<File>, everything else should as well. If this patch is accepted, I will make SBFile use a shared_ptr I will remove FileOps from future patches and use subclasses of File instead. Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67891 llvm-svn: 373090
2019-04-26[ScriptInterpreter] Pass the debugger instead of the command interpreterJonas Devlieghere
As discussed in D61090, there's no good reason for the script interpreter to depend on the command interpreter. When looking at the code, it becomes clear that we mostly use the command interpreter as a way to access the debugger. Hence, it makes more sense to just pass that to the script interpreter directly. This is part 1 out of 2. I have another patch in the pipeline that changes the ownership of the script interpreter to the debugger as well, but I didn't get around to finish that today. Differential revision: https://reviews.llvm.org/D61172 llvm-svn: 359330
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere
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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-11Remove header grouping comments.Jonas Devlieghere
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
2018-07-12Get rid of the C-string parameter in DoExecuteRaphael Isemann
Summary: This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function, making the code simpler and less memory unsafe. There seems to be a assumption in some command objects that this parameter could be a nullptr, but from what I can see the rest of the API doesn't actually allow this (and other command objects and related code pieces dereference this parameter without any checks). Especially CommandObjectRegexCommand has error handling code for a nullptr that is now gone. Reviewers: davide, jingham, teemperor Reviewed By: teemperor Subscribers: jingham, lldb-commits Differential Revision: https://reviews.llvm.org/D49207 llvm-svn: 336955
2017-03-21Move StringList from Core -> Utility.Zachary Turner
llvm-svn: 298412
2017-02-06Switch std::call_once to llvm::call_onceKamil Rytarowski
Summary: The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms. This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg, emaste, mehdi_amini, clayborg Reviewed By: labath, clayborg Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29288 llvm-svn: 294202
2017-02-02Move classes from Core -> Utility.Zachary Turner
This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-01-31[CMake] [4/4] Update a batch of pluginsChris Bieneman
This is extending the updates from r293696 to more LLDB plugins. llvm-svn: 293701
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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
2016-01-28Remove autoconf support from source directories.Eugene Zelenko
Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
2015-10-19Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko
source/Plugins; other minor fixes. Differential Revision: http://reviews.llvm.org/D13840 llvm-svn: 250721
2015-08-05Bug 24332 - Fix the build of lldb under GNU/Linux when using autotoolsSylvestre Ledru
Reviewers: loladiro, jingham, emaste, zturner, brucem Subscribers: tberghammer, danalbert, srhines, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D11717 llvm-svn: 244039
2015-07-30Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner
Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681