summaryrefslogtreecommitdiff
path: root/lldb/source/API/SBEvent.cpp
AgeCommit message (Collapse)Author
2024-04-24[lldb][nfc] Move broadcaster class strings away from ConstString (#89690)Alex Langford
These are hardcoded strings that are already present in the data section of the binary, no need to immediately place them in the ConstString StringPools. Lots of code still calls `GetBroadcasterClass` and places the return value into a ConstString. Changing that would be a good follow-up. Additionally, calls to these functions are still wrapped in ConstStrings at the SBAPI layer. This is because we must guarantee the lifetime of all strings handed out publicly.
2024-01-26[lldb][NFCI] Constrain EventDataBytes creation (#79508)Alex Langford
There are 3 ways to create an EventDataBytes object: (const char *), (llvm::StringRef), and (const void *, size_t len). All of these cases can be handled under `llvm::StringRef`. Additionally, this allows us to remove the otherwise unused `SetBytes`, `SwapBytes`, and `SetBytesFromCString` methods.
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
2023-05-18[lldb] Guarantee the lifetimes of all strings returned from SBAPIAlex Langford
LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804
2023-04-11[lldb] Change return type of EventData::GetFlavorAlex Langford
There's no reason these strings need to be in the ConstString StringPool, they're already string literals with static lifetime. I plan on addressing other similar functions in follow up commits. Differential Revision: https://reviews.llvm.org/D147833
2022-01-20[lldb] Decouple instrumentation from the reproducersJonas Devlieghere
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712
2022-01-09[lldb] Remove LLDB_RECORD_RESULT macroJonas Devlieghere
2022-01-09[lldb] Remove reproducer instrumentationJonas Devlieghere
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details. [1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html Differential revision: https://reviews.llvm.org/D116847
2022-01-02[API] Remove redundant member initialization (NFC)Kazu Hirata
Identified with readability-redundant-member-init.
2021-06-09[lldb] Use C++11 default member initializersJonas Devlieghere
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy and the modernize-use-default-member-init check. $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix This is a mass-refactoring patch and this commit will be added to .git-blame-ignore-revs. Differential revision: https://reviews.llvm.org/D103483
2020-02-17[lldb] Replace empty ctor en dtor bodies with =default (NFC)Jonas Devlieghere
Use = default instead of empty constructor and destructor bodies in the API layer.
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
2020-01-07[lldb][NFC] Use static_cast instead of reinterpret_cast where possibleRaphael Isemann
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2019-05-23[lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
2019-04-03[Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere
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
2019-03-19[lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny
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
2019-03-11Add "operator bool" to SB APIsPavel Labath
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
2019-03-07[SBAPI] Log from record macroJonas Devlieghere
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
2019-03-06[Reproducers] Add SBReproducer macrosJonas Devlieghere
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
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-12-14Move Broadcaster+Listener+Event combo from Core into UtilityPavel Labath
Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module. This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board. Reviewers: zturner, jingham, teemperor, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D55361 llvm-svn: 349157
2018-04-30Reflow paragraphs in comments.Adrian Prantl
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2017-02-05Remove LIBLLDB_LOG_VERBOSE categoryPavel Labath
Summary: Per discussion in D28616, having two ways two request logging (log enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This removes the first option and standardizes all code to use the second one. I've added a LLDB_LOGV macro as a shorthand for if(log && log->GetVerbose()) and switched most of the affected log statements to use that (I've only left a couple of cases that were doing complex computations in an if(log) block). Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D29510 llvm-svn: 294113
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
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
2015-05-29Don't #include "lldb-python.h" from anywhere.Zachary Turner
Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
2014-09-29This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham
more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
2014-04-04sweep up -Wformat warnings from gccSaleem Abdulrasool
This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2013-03-27<rdar://problem/13521159>Greg Clayton
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2012-12-05Fix Linux build warnings due to redefinition of macros:Daniel Malea
- add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
2012-02-16Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham
class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2011-11-13<rdar://problem/10126482>Greg Clayton
Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2010-12-05Fixed a crasher when trying to get event data flavors on events that don'tGreg Clayton
have event data. llvm-svn: 120948
2010-11-06Modified all logging calls to hand out shared pointers to make sure weGreg Clayton
don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
2010-11-05Added copy constructors and assignment operators to all lldb::SB* classesGreg Clayton
so we don't end up with weak exports with some compilers. llvm-svn: 118312
2010-10-31Cleaned up the API logging a lot more to reduce redundant information and Greg Clayton
keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-30Improved API logging.Greg Clayton
llvm-svn: 117772
2010-10-29Modified the lldb_private::TypeList to use a std::multimap for quicker lookupGreg Clayton
by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-26Clean up the API logging code:Caroline Tice
- Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-26First pass at adding logging capabilities for the API functions. At the momentCaroline Tice
it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-09-22Remove all the __repr__ methods from the API/*.h files, and put themCaroline Tice
into python-extensions.swig, which gets included into lldb.swig, and adds them back into the classes when swig generates it's C++ file. This keeps the Python stuff out of the general API classes. Also fixed a small bug in the copy constructor for SBSymbolContext. llvm-svn: 114602
2010-09-20Fix indentations.Caroline Tice
llvm-svn: 114326
2010-09-20Add GetDescription() and __repr__ () methods to most API classes, to allowCaroline Tice
"print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-15Remove unnecessary/inappropriate output-printing functions fromCaroline Tice
the API. llvm-svn: 113993
2010-06-23Very large changes that were needed in order to allow multiple connectionsGreg Clayton
to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-09And some more include line fixes.Eli Friedman
llvm-svn: 105704
2010-06-08Initial checkin of lldb code from internal Apple repo.Chris Lattner
llvm-svn: 105619