summaryrefslogtreecommitdiff
path: root/lldb/source/Expression/FunctionCaller.cpp
AgeCommit message (Collapse)Author
2025-06-09[lldb] Use llvm::find (NFC) (#143338)Kazu Hirata
This patch should be mostly obvious, but in one place, this patch changes: const auto &it = std::find(...) to: auto it = llvm::find(...) We do not need to bind to a temporary with const ref.
2025-05-19[lldb] Use llvm::is_contained (NFC) (#140466)Kazu Hirata
2024-12-13[lldb] Add a progress event for executing an expression (#119757)Adrian Prantl
Expressions can take arbitrary amounts of time to run, so IDEs might want to be informed about the fact that an expression is currently being executed. rdar://141253078
2024-10-24[lldb] Move ValueObject into its own library (NFC) (#113393)Jonas Devlieghere
ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: ``` find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; ```
2024-10-11Support inline diagnostics in CommandReturnObject (#110901)Adrian Prantl
and implement them for dwim-print (a.k.a. `p`) as an example. The next step will be to expose them as structured data in SBCommandReturnObject.
2024-09-05Factor Process::ExecutionResultAsCString() into a global function (NFC)Adrian Prantl
2024-05-03[lldb] Create a single Severity enum in lldb-enumerations (#90917)Jonas Devlieghere
We have 3 different enums all expressing severity (info, warning, error). Remove all uses with a new Severity enum in lldb-enumerations.h.
2022-11-09Don't try to create Expressions when the process is running.Jim Ingham
We generally prohibit this at a higher level - for instance requiring the process to be stopped for "expr". But when we trigger an expression for internal purposes (e.g. to fetch types from the ObjC runtime) we weren't checking the process state. Now we explicitly check this at the very start of the job so we don't get into bad states. Differential Revision: https://reviews.llvm.org/D137684
2022-07-28[NFC] Improve FileSpec internal APIs and usage in preparation for adding ↵Greg Clayton
caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-27[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 3Slava Gurevich
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from scan.coverity.com/projects/llvm: 1355854, 1347549, 1316348, 1372028, 1431625, 1315634, 1315637, 1355855, 1364803, 1420505, 1420563, 1420685, 1366014, 1203966, 1204029, 1204031, 1204032, 1328411, 1325969, 1325968, 1374921, 1094809 Differential Revision: https://reviews.llvm.org/D130602
2022-07-23Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for ↵Nico Weber
adding caching of resolved/absolute." and follow-ups This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d. It broke the build on Windows, see comments on https://reviews.llvm.org/D130309 It also reverts these follow-ups: Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14. Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24. Revert "Cache the value for absolute path in FileSpec." This reverts commit dabe877248b85b34878e75d5510339325ee087d0.
2022-07-22[NFC] Improve FileSpec internal APIs and usage in preparation for adding ↵Greg Clayton
caching of resolved/absolute. The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130309
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath
2021-11-11[lldb][NFC] Inclusive Language: rename master plan to controlling planQuinn Pham
[NFC] As part of using inclusive language within the llvm project, this patch renames master plan to controlling plan in lldb. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D113019
2021-02-24[lldb] Support debugging utility functionsJonas Devlieghere
LLDB uses utility functions to run code in the inferior for its own internal purposes, such as reading classes from the Objective-C runtime for example. Because these expressions should be transparent to the user, we ignore breakpoints and unwind the stack on errors, which makes them hard to debug. This patch adds a new setting target.debug-utility-expression that, when enabled, changes these options to facilitate debugging. It enables breakpoints, disables unwinding and writes out the utility function source code to disk so it shows up in the source view. Differential revision: https://reviews.llvm.org/D97249
2021-02-12Make the error condition in Value::ValueType explicit (NFC)Adrian Prantl
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage. https://reviews.llvm.org/D96537
2020-05-21Handle the case where a thread exits while we are running a function on it.Jim Ingham
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-11-12[lldb][NFC] Move LLVM RTTI implementation from enum to static ID variableRaphael Isemann
Summary: swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI with a static ID variable instead of a centralised enum we can drop that patch. Reviewers: labath, davide Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D70070
2019-07-24[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
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-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-04-08Rename Target::GetSharedModule to Target::GetOrCreateModule.Jason Molenda
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
2019-03-13Fix an invalid static cast in ClangExpressionParser.cppAdrian Prantl
This was found by the green dragon sanitizer bot. rdar://problem/48536644 Differential Revision: https://reviews.llvm.org/D59314 llvm-svn: 356090
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-08-07Move RegisterValue,Scalar,State from Core to UtilityPavel Labath
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
2018-06-28Add a way to load an image using a library name and list of paths.Jim Ingham
This provides an efficient (at least on Posix platforms) way to offload to the target process the search & loading of a library when all we have are the library name and a set of potential candidate locations. <rdar://problem/40905971> llvm-svn: 335912
2018-05-31Set m_struct_valid to initial value in ctor. Jason Molenda
Patch from Tom Tromey <ttromey@mozilla.com>. Differential Revision: https://reviews.llvm.org/D47481 llvm-svn: 333690
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-05-12Rename Error -> Status.Zachary Turner
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner
llvm-svn: 296943
2017-03-03Move Log from Core -> Utility.Zachary Turner
All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
2016-11-12Make DiagnosticsManager functions take StringRefs.Zachary Turner
llvm-svn: 286730
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-03-21Compilation can end up calling functions (e.g. to resolve indirect ↵Jim Ingham
functions) so I added a way for compilation to take a "thread to use for compilation". If it isn't set then the compilation will use the currently selected thread. This should help keep function execution to the one thread intended. llvm-svn: 263972
2016-03-19Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan
We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
2015-09-25Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan
There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
2015-09-18Reduce inclusion of clang headers.Bruce Mitchener
Summary: With the recent changes to separate clang from the core structures of LLDB, many inclusions of clang headers can be removed. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12954 llvm-svn: 248004
2015-09-15This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham
that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720