maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Expression/Materializer.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1452 lines
47 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers 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-24 15:23:27 +08:00
//===-- Materializer.cpp --------------------------------------------------===//
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
//
//===----------------------------------------------------------------------===//
#include "lldb/Expression/Materializer.h"
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
#include "lldb/Core/DumpDataExtractor.h"
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
#include "lldb/Core/ValueObjectConstResult.h"
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
#include "lldb/Core/ValueObjectVariable.h"
Now persistent expression data no longer lives with the Target, but rather with the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
2015-10-01 03:57:57 +08:00
#include "lldb/Expression/ExpressionVariable.h"
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
#include "lldb/Symbol/Symbol.h"
#include "lldb/Symbol/Type.h"
#include "lldb/Symbol/Variable.h"
#include "lldb/Target/ExecutionContext.h"
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
#include "lldb/Target/RegisterContext.h"
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
#include "lldb/Target/StackFrame.h"
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
#include "lldb/Target/Target.h"
Fixed a problem with materialization and dematerialization of registers that caused conditional breakpoint expressions not to work properly. Also added a testcase. <rdar://problem/14129252> llvm-svn: 184451
2013-06-21 02:42:16 +08:00
#include "lldb/Target/Thread.h"
[lldb] Rename Logging.h to LLDBLog.h and clean up includes 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-03 20:26:10 +08:00
#include "lldb/Utility/LLDBLog.h"
Move Log from Core -> Utility. 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
2017-03-04 04:56:28 +08:00
#include "lldb/Utility/Log.h"
Move RegisterValue,Scalar,State from Core to Utility 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-08-07 19:07:21 +08:00
#include "lldb/Utility/RegisterValue.h"
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Use std::make_shared in LLDB (NFC) 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
2019-02-12 07:13:08 +08:00
#include <memory>
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
using namespace lldb_private;
uint32_t Materializer::AddStructMember(Entity &entity) {
uint32_t size = entity.GetSize();
uint32_t alignment = entity.GetAlignment();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Hand over the job of laying out the argument structure to the Materializer. Materialization is still done by the ClangExpressionDeclMap; this will be the next thing to move. Also fixed a layout bug that this uncovered. llvm-svn: 179318
2013-04-12 05:16:36 +08:00
if (m_current_offset == 0)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
m_struct_alignment = alignment;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
if (m_current_offset % alignment)
m_current_offset += (alignment - (m_current_offset % alignment));
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
ret = m_current_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
m_current_offset += size;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
return ret;
}
class EntityPersistentVariable : public Materializer::Entity {
public:
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
EntityPersistentVariable(lldb::ExpressionVariableSP &persistent_variable_sp,
Materializer::PersistentVariableDelegate *delegate)
: Entity(), m_persistent_variable_sp(persistent_variable_sp),
m_delegate(delegate) {
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
// Hard-coding to maximum size of a pointer since persistent variables are
// materialized by reference
m_size = 8;
m_alignment = 8;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Rename Error -> Status. 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-05-12 12:51:55 +08:00
void MakeAllocation(IRMemoryMap &map, Status &err) {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// Allocate a spare memory area to store the persistent variable's
// contents.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status allocate_error;
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
const bool zero_memory = false;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
lldb::addr_t mem = map.Malloc(
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_persistent_variable_sp->GetByteSize().value_or(0), 8,
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
lldb::ePermissionsReadable | lldb::ePermissionsWritable,
IRMemoryMap::eAllocationPolicyMirror, zero_memory, allocate_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!allocate_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't allocate a memory area to store %s: %s",
m_persistent_variable_sp->GetName().GetCString(),
allocate_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log, "Allocated %s (0x%" PRIx64 ") successfully",
m_persistent_variable_sp->GetName().GetCString(), mem);
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
// Put the location of the spare memory into the live data of the
// ValueObject.
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
m_persistent_variable_sp->m_live_sp = ValueObjectConstResult::Create(
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
map.GetBestExecutionContextScope(),
Removed a needless cast to ClangExpressionVariable. llvm-svn: 247910
2015-09-18 02:19:12 +08:00
m_persistent_variable_sp->GetCompilerType(),
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
m_persistent_variable_sp->GetName(), mem, eAddressTypeLoad,
map.GetAddressByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
// Clear the flag if the variable will never be deallocated.
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix some typos: * transfered => transferred * unkown => unknown * sucessfully => successfully llvm-svn: 215367
2014-08-12 02:06:28 +08:00
if (m_persistent_variable_sp->m_flags &
ExpressionVariable::EVKeepInTarget) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status leak_error;
Fix some typos: * transfered => transferred * unkown => unknown * sucessfully => successfully llvm-svn: 215367
2014-08-12 02:06:28 +08:00
map.Leak(mem, leak_error);
m_persistent_variable_sp->m_flags &=
~ExpressionVariable::EVNeedsAllocation;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
// Write the contents of the variable to the area.
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
map.WriteMemory(mem, m_persistent_variable_sp->GetValueBytes(),
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_persistent_variable_sp->GetByteSize().value_or(0),
Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish) This cleanup patch unifies all methods called GetByteSize() in the ValueObject hierarchy to return an optional, like the methods in CompilerType do. This means fewer magic 0 values, which could fix bugs down the road in languages where types can have a size of zero, such as Swift and C (but not C++). Differential Revision: https://reviews.llvm.org/D84285 This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
2020-07-25 23:27:21 +08:00
write_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
if (!write_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't write %s to the target: %s",
m_persistent_variable_sp->GetName().AsCString(),
Fixed a bug where persistent variables did not live as long as they needed to. This led to equality tests involving persistent variables often failing or succeeding when they had no business doing so. To do this, I introduced the ability for a memory allocation to "leak" - that is, to persist in the process beyond the lifetime of the expression. Hand-declared persistent variables do this now. <rdar://problem/13956311> llvm-svn: 182528
2013-05-23 06:49:06 +08:00
write_error.AsCString());
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
return;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fixed a bug where persistent variables did not live as long as they needed to. This led to equality tests involving persistent variables often failing or succeeding when they had no business doing so. To do this, I introduced the ability for a memory allocation to "leak" - that is, to persist in the process beyond the lifetime of the expression. Hand-declared persistent variables do this now. <rdar://problem/13956311> llvm-svn: 182528
2013-05-23 06:49:06 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
void DestroyAllocation(IRMemoryMap &map, Status &err) {
Status deallocate_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
map.Free((lldb::addr_t)m_persistent_variable_sp->m_live_sp->GetValue()
.GetScalar()
.ULongLong(),
deallocate_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_live_sp.reset();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!deallocate_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't deallocate memory for %s: %s",
m_persistent_variable_sp->GetName().GetCString(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
deallocate_error.AsCString());
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
void Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityPersistentVariable::Materialize [address = 0x%" PRIx64
", m_name = %s, m_flags = 0x%hx]",
(uint64_t)load_addr,
m_persistent_variable_sp->GetName().AsCString(),
m_persistent_variable_sp->m_flags);
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
if (m_persistent_variable_sp->m_flags &
ExpressionVariable::EVNeedsAllocation) {
MakeAllocation(map, err);
m_persistent_variable_sp->m_flags |=
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
ExpressionVariable::EVIsLLDBAllocated;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!err.Success())
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
return;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
if ((m_persistent_variable_sp->m_flags &
ExpressionVariable::EVIsProgramReference &&
m_persistent_variable_sp->m_live_sp) ||
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_flags &
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
ExpressionVariable::EVIsLLDBAllocated) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WriteScalarToMemory(
load_addr,
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_live_sp->GetValue().GetScalar(),
Revert "Fix bug with register values byte order in expression evaluation." This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot. See details in: https://llvm.org/bugs/show_bug.cgi?id=26758 llvm-svn: 262156
2016-02-28 06:48:50 +08:00
map.GetAddressByteSize(), write_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!write_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't write the location of %s to memory: %s",
m_persistent_variable_sp->GetName().AsCString(),
write_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
} else {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"no materialization happened for persistent variable %s",
m_persistent_variable_sp->GetName().AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
lldb::addr_t process_address, lldb::addr_t frame_top,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t frame_bottom, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityPersistentVariable::Dematerialize [address = 0x%" PRIx64
", m_name = %s, m_flags = 0x%hx]",
(uint64_t)process_address + m_offset,
m_persistent_variable_sp->GetName().AsCString(),
m_persistent_variable_sp->m_flags);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (m_delegate) {
m_delegate->DidDematerialize(m_persistent_variable_sp);
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
if ((m_persistent_variable_sp->m_flags &
ExpressionVariable::EVIsLLDBAllocated) ||
(m_persistent_variable_sp->m_flags &
ExpressionVariable::EVIsProgramReference)) {
if (m_persistent_variable_sp->m_flags &
ExpressionVariable::EVIsProgramReference &&
!m_persistent_variable_sp->m_live_sp) {
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
// If the reference comes from the program, then the
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// ClangExpressionVariable's live variable data hasn't been set up yet.
// Do this now.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
lldb::addr_t location;
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status read_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadPointerFromMemory(&location, load_addr, read_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!read_error.Success()) {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
err.SetErrorStringWithFormat(
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
"couldn't read the address of program-allocated variable %s: %s",
m_persistent_variable_sp->GetName().GetCString(),
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
read_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_persistent_variable_sp->m_live_sp = ValueObjectConstResult::Create(
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
map.GetBestExecutionContextScope(),
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
m_persistent_variable_sp.get()->GetCompilerType(),
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
m_persistent_variable_sp->GetName(), location, eAddressTypeLoad,
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_persistent_variable_sp->GetByteSize().value_or(0));
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (frame_top != LLDB_INVALID_ADDRESS &&
Performance optimizations to ClangUserExpression, mostly related to management of the stack frame for the interpreter. - First, if the expression can be interpreted, allocate the stack frame in the target process (to make sure pointers are valid) but only read/write to the copy in the host's memory. - Second, keep the memory allocations for the stack frame and the materialized struct as member variables of ClangUserExpression. This avoids memory allocations and deallocations each time the expression runs. <rdar://problem/13043685> llvm-svn: 180664
2013-04-27 10:19:33 +08:00
frame_bottom != LLDB_INVALID_ADDRESS && location >= frame_bottom &&
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
location <= frame_top) {
// If the variable is resident in the stack frame created by the
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// expression, then it cannot be relied upon to stay around. We
// treat it as needing reallocation.
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_flags |=
ExpressionVariable::EVIsLLDBAllocated;
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
m_persistent_variable_sp->m_flags |=
ExpressionVariable::EVNeedsAllocation;
m_persistent_variable_sp->m_flags |=
ExpressionVariable::EVNeedsFreezeDry;
m_persistent_variable_sp->m_flags &=
~ExpressionVariable::EVIsProgramReference;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
}
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
lldb::addr_t mem = m_persistent_variable_sp->m_live_sp->GetValue()
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
.GetScalar()
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
.ULongLong();
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!m_persistent_variable_sp->m_live_sp) {
err.SetErrorStringWithFormat(
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
"couldn't find the memory area used to store %s",
m_persistent_variable_sp->GetName().GetCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
if (m_persistent_variable_sp->m_live_sp->GetValue()
.GetValueAddressType() != eAddressTypeLoad) {
err.SetErrorStringWithFormat(
"the address of the memory area for %s is in an incorrect format",
m_persistent_variable_sp->GetName().GetCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
if (m_persistent_variable_sp->m_flags &
ExpressionVariable::EVNeedsFreezeDry ||
m_persistent_variable_sp->m_flags &
ExpressionVariable::EVKeepInTarget) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log, "Dematerializing %s from 0x%" PRIx64 " (size = %llu)",
m_persistent_variable_sp->GetName().GetCString(),
(uint64_t)mem,
Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish) This cleanup patch unifies all methods called GetByteSize() in the ValueObject hierarchy to return an optional, like the methods in CompilerType do. This means fewer magic 0 values, which could fix bugs down the road in languages where types can have a size of zero, such as Swift and C (but not C++). Differential Revision: https://reviews.llvm.org/D84285 This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
2020-07-25 23:27:21 +08:00
(unsigned long long)m_persistent_variable_sp->GetByteSize()
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
.value_or(0));
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
// Read the contents of the spare memory area
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->ValueUpdated();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status read_error;
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
map.ReadMemory(m_persistent_variable_sp->GetValueBytes(), mem,
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_persistent_variable_sp->GetByteSize().value_or(0),
read_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
if (!read_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't read the contents of %s from memory: %s",
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->GetName().GetCString(),
read_error.AsCString());
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
return;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
m_persistent_variable_sp->m_flags &=
~ExpressionVariable::EVNeedsFreezeDry;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
} else {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"no dematerialization happened for persistent variable %s",
m_persistent_variable_sp->GetName().AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
lldb::ProcessSP process_sp =
map.GetBestExecutionContextScope()->CalculateProcess();
if (!process_sp || !process_sp->CanJIT()) {
// Allocations are not persistent so persistent variables cannot stay
// materialized.
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
m_persistent_variable_sp->m_flags |=
ExpressionVariable::EVNeedsAllocation;
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
DestroyAllocation(map, err);
if (!err.Success())
return;
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
} else if (m_persistent_variable_sp->m_flags &
ExpressionVariable::EVNeedsAllocation &&
!(m_persistent_variable_sp->m_flags &
ExpressionVariable::EVKeepInTarget)) {
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
DestroyAllocation(map, err);
if (!err.Success())
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void DumpToLog(IRMemoryMap &map, lldb::addr_t process_address,
Log *log) override {
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
StreamString dump_stream;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status err;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityPersistentVariable (%s)\n",
load_addr,
m_persistent_variable_sp->GetName().AsCString());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Pointer:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
DataBufferHeap data(m_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Target:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
lldb::addr_t target_address;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadPointerFromMemory(&target_address, load_addr, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
} else {
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
DataBufferHeap data(m_persistent_variable_sp->GetByteSize().value_or(0),
0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
map.ReadMemory(data.GetBytes(), target_address,
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_persistent_variable_sp->GetByteSize().value_or(0),
err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
target_address);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->PutString(dump_stream.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Wipe(IRMemoryMap &map, lldb::addr_t process_address) override {}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
This patch separates the generic portion of ClangExpressionVariable, which stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 llvm-svn: 246871
2015-09-05 04:49:51 +08:00
lldb::ExpressionVariableSP m_persistent_variable_sp;
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
Materializer::PersistentVariableDelegate *m_delegate;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
uint32_t Materializer::AddPersistentVariable(
lldb::ExpressionVariableSP &persistent_variable_sp,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
PersistentVariableDelegate *delegate, Status &err) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
[lldb] Use std::make_unique<> (NFC) Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-25 08:44:33 +08:00
*iter = std::make_unique<EntityPersistentVariable>(persistent_variable_sp,
delegate);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityVariable : public Materializer::Entity {
public:
EntityVariable(lldb::VariableSP &variable_sp)
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
: Entity(), m_variable_sp(variable_sp) {
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
// Hard-coding to maximum size of a pointer since all variables are
// materialized by reference
Hand over the job of laying out the argument structure to the Materializer. Materialization is still done by the ClangExpressionDeclMap; this will be the next thing to move. Also fixed a layout bug that this uncovered. llvm-svn: 179318
2013-04-12 05:16:36 +08:00
m_size = 8;
m_alignment = 8;
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
m_is_reference =
m_variable_sp->GetType()->GetForwardCompilerType().IsReferenceType();
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityVariable::Materialize [address = 0x%" PRIx64
", m_variable_sp = %s]",
(uint64_t)load_addr, m_variable_sp->GetName().AsCString());
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
ExecutionContextScope *scope = frame_sp.get();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!scope)
scope = map.GetBestExecutionContextScope();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
lldb::ValueObjectSP valobj_sp =
ValueObjectVariable::Create(scope, m_variable_sp);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!valobj_sp) {
err.SetErrorStringWithFormat(
"couldn't get a value object for variable %s",
m_variable_sp->GetName().AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status valobj_error = valobj_sp->GetError();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (valobj_error.Fail()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the value of variable %s: %s",
m_variable_sp->GetName().AsCString(),
valobj_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (m_is_reference) {
DataExtractor valobj_extractor;
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status extract_error;
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
valobj_sp->GetData(valobj_extractor, extract_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
if (!extract_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't read contents of reference variable %s: %s",
m_variable_sp->GetName().AsCString(), extract_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
lldb::offset_t offset = 0;
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
lldb::addr_t reference_addr = valobj_extractor.GetAddress(&offset);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
map.WritePointerToMemory(load_addr, reference_addr, write_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
if (!write_error.Success()) {
err.SetErrorStringWithFormat("couldn't write the contents of reference "
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
"variable %s to memory: %s",
m_variable_sp->GetName().AsCString(),
write_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
} else {
Fixed a bug where the expression parser doesn't materialize a variable in a register correctly if the variable is a pointer. This fixes a regression introduced by my commit of Oct. 22nd (r193191). llvm-svn: 198718
2014-01-08 07:15:26 +08:00
AddressType address_type = eAddressTypeInvalid;
const bool scalar_is_load_address = false;
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
lldb::addr_t addr_of_valobj =
valobj_sp->GetAddressOf(scalar_is_load_address, &address_type);
Simplified the code that materializes a variable, obviating the need to create a new ValueObject. llvm-svn: 193191
2013-10-23 04:01:17 +08:00
if (addr_of_valobj != LLDB_INVALID_ADDRESS) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
Simplified the code that materializes a variable, obviating the need to create a new ValueObject. llvm-svn: 193191
2013-10-23 04:01:17 +08:00
map.WritePointerToMemory(load_addr, addr_of_valobj, write_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!write_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
"couldn't write the address of variable %s to memory: %s",
m_variable_sp->GetName().AsCString(), write_error.AsCString());
return;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
DataExtractor data;
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status extract_error;
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
valobj_sp->GetData(data, extract_error);
if (!extract_error.Success()) {
err.SetErrorStringWithFormat("couldn't get the value of %s: %s",
m_variable_sp->GetName().AsCString(),
extract_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (m_temporary_allocation != LLDB_INVALID_ADDRESS) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"trying to create a temporary region for %s but one exists",
m_variable_sp->GetName().AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Thread ExecutionContextScope through GetByteSize where possible (NFC-ish) This patch has no effect for C and C++. In more dynamic languages, such as Objective-C and Swift GetByteSize() needs to call into the language runtime, so it's important to pass one in where possible. My primary motivation for this is some work I'm doing on the Swift branch, however, it looks like we are also seeing warnings in Objective-C that this may resolve. Everything in the SymbolFile hierarchy still passes in nullptrs, because we don't have an execution context in SymbolFile, since SymbolFile transcends processes. Differential Revision: https://reviews.llvm.org/D84267
2020-07-22 04:53:43 +08:00
if (data.GetByteSize() < m_variable_sp->GetType()->GetByteSize(scope)) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
if (data.GetByteSize() == 0 &&
Simplify Boolean expressions This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
2018-12-15 08:15:33 +08:00
!m_variable_sp->LocationExpression().IsValid()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("the variable '%s' has no location, "
"it may have been optimized out",
m_variable_sp->GetName().AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Support floating point values in 128-bit SSE vector registers The System-V x86_64 ABI requires floating point values to be passed in 128-but SSE vector registers (xmm0, ...). When printing such a variable this currently yields an <invalid load address>. This patch makes LLDB's DWARF expression evaluator accept 128-bit registers as scalars. It also relaxes the check that the size of the result of the DWARF expression be equal to the size of the variable to a greater-than. DWARF defers to the ABI how smaller values are being placed in a larger register. Implementation note: I found the code in Value::SetContext() that changes the m_value_type after the fact to be questionable. I added a sanity check that the Value's memory buffer has indeed been written to (this is necessary, because we may have a scalar value in a vector register), but really I feel like this is the wrong place to be setting it. Reviewed by Greg Clayton. http://reviews.llvm.org/D17897 rdar://problem/24944340 llvm-svn: 262947
2016-03-09 02:35:09 +08:00
err.SetErrorStringWithFormat(
"size of variable %s (%" PRIu64
") is larger than the ValueObject's size (%" PRIu64 ")",
Fixed printf warnings. The GetByteSize() results return uint64_t values, not size_t values. llvm-svn: 194587
2013-11-14 02:01:16 +08:00
m_variable_sp->GetName().AsCString(),
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
m_variable_sp->GetType()->GetByteSize(scope).value_or(0),
Make Type::GetByteSize optional (NFC) This is a continuation of my quest to make the size 0 a supported value. This reapplies r352394 with additional PDB parser fixes prepared by Pavel Labath! Differential Revision: https://reviews.llvm.org/D57273 llvm-svn: 352521
2019-01-30 01:52:34 +08:00
data.GetByteSize());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
return;
}
[Symbol] GetTypeBitAlign() should return None in case of failure. Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
2019-08-13 04:03:19 +08:00
llvm::Optional<size_t> opt_bit_align =
[CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign. llvm-svn: 368620
2019-08-13 05:49:54 +08:00
m_variable_sp->GetType()->GetLayoutCompilerType().GetTypeBitAlign(scope);
[Symbol] GetTypeBitAlign() should return None in case of failure. Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
2019-08-13 04:03:19 +08:00
if (!opt_bit_align) {
err.SetErrorStringWithFormat("can't get the type alignment for %s",
m_variable_sp->GetName().AsCString());
return;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
[Symbol] GetTypeBitAlign() should return None in case of failure. Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
2019-08-13 04:03:19 +08:00
size_t byte_align = (*opt_bit_align + 7) / 8;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status alloc_error;
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
const bool zero_memory = false;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
m_temporary_allocation = map.Malloc(
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
data.GetByteSize(), byte_align,
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
lldb::ePermissionsReadable | lldb::ePermissionsWritable,
IRMemoryMap::eAllocationPolicyMirror, zero_memory, alloc_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
m_temporary_allocation_size = data.GetByteSize();
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Use std::make_shared in LLDB (NFC) 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
2019-02-12 07:13:08 +08:00
m_original_data = std::make_shared<DataBufferHeap>(data.GetDataStart(),
data.GetByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Better error reporting when a variable can't be read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
2014-03-01 06:27:53 +08:00
if (!alloc_error.Success()) {
err.SetErrorStringWithFormat(
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
"couldn't allocate a temporary region for %s: %s",
m_variable_sp->GetName().AsCString(), alloc_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
map.WriteMemory(m_temporary_allocation, data.GetDataStart(),
Support floating point values in 128-bit SSE vector registers The System-V x86_64 ABI requires floating point values to be passed in 128-but SSE vector registers (xmm0, ...). When printing such a variable this currently yields an <invalid load address>. This patch makes LLDB's DWARF expression evaluator accept 128-bit registers as scalars. It also relaxes the check that the size of the result of the DWARF expression be equal to the size of the variable to a greater-than. DWARF defers to the ABI how smaller values are being placed in a larger register. Implementation note: I found the code in Value::SetContext() that changes the m_value_type after the fact to be questionable. I added a sanity check that the Value's memory buffer has indeed been written to (this is necessary, because we may have a scalar value in a vector register), but really I feel like this is the wrong place to be setting it. Reviewed by Greg Clayton. http://reviews.llvm.org/D17897 rdar://problem/24944340 llvm-svn: 262947
2016-03-09 02:35:09 +08:00
data.GetByteSize(), write_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Harden the Materializer logic against types that don't know their bit alignment. llvm-svn: 199173
2014-01-14 09:14:40 +08:00
if (!write_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't write to the temporary region for %s: %s",
m_variable_sp->GetName().AsCString(), write_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status pointer_write_error;
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, m_temporary_allocation,
pointer_write_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!pointer_write_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't write the address of the temporary region for %s: %s",
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
m_variable_sp->GetName().AsCString(),
pointer_write_error.AsCString());
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
}
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
lldb::addr_t process_address, lldb::addr_t frame_top,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t frame_bottom, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityVariable::Dematerialize [address = 0x%" PRIx64
", m_variable_sp = %s]",
(uint64_t)load_addr, m_variable_sp->GetName().AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (m_temporary_allocation != LLDB_INVALID_ADDRESS) {
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
ExecutionContextScope *scope = frame_sp.get();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!scope)
scope = map.GetBestExecutionContextScope();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
lldb::ValueObjectSP valobj_sp =
ValueObjectVariable::Create(scope, m_variable_sp);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!valobj_sp) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't get a value object for variable %s",
m_variable_sp->GetName().AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
lldb_private::DataExtractor data;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status extract_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish) This cleanup patch unifies all methods called GetByteSize() in the ValueObject hierarchy to return an optional, like the methods in CompilerType do. This means fewer magic 0 values, which could fix bugs down the road in languages where types can have a size of zero, such as Swift and C (but not C++). Differential Revision: https://reviews.llvm.org/D84285 This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
2020-07-25 23:27:21 +08:00
map.GetMemoryData(data, m_temporary_allocation,
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
valobj_sp->GetByteSize().value_or(0), extract_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
if (!extract_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for variable %s",
m_variable_sp->GetName().AsCString());
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
bool actually_write = true;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
if (m_original_data) {
if ((data.GetByteSize() == m_original_data->GetByteSize()) &&
Fixed a flipped conditional when writing back the values of variables in the Materializer. The Materializer should not write the variable back if its new value is the *same* as the old value, not if the new value is *different*. <rdar://problem/16712205> llvm-svn: 207148
2014-04-25 05:43:04 +08:00
!memcmp(m_original_data->GetBytes(), data.GetDataStart(),
data.GetByteSize())) {
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
actually_write = false;
}
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status set_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
if (actually_write) {
valobj_sp->SetData(data, set_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
if (!set_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't write the new contents of %s back into the variable",
m_variable_sp->GetName().AsCString());
return;
}
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status free_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
map.Free(m_temporary_allocation, free_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!free_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't free the temporary region for %s: %s",
m_variable_sp->GetName().AsCString(), free_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
m_original_data.reset();
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
m_temporary_allocation = LLDB_INVALID_ADDRESS;
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
m_temporary_allocation_size = 0;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void DumpToLog(IRMemoryMap &map, lldb::addr_t process_address,
Log *log) override {
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
StreamString dump_stream;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityVariable\n", load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status err;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
lldb::addr_t ptr = LLDB_INVALID_ADDRESS;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
{
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.Printf("Pointer:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
DataBufferHeap data(m_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
DataExtractor extractor(data.GetBytes(), data.GetByteSize(),
map.GetByteOrder(), map.GetAddressByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[lldb] Fix a couple of use-of-uninit-var errors in Materializer.cpp These were probably not picked up before because they only run when logging is enabled.
2022-01-26 23:46:19 +08:00
lldb::offset_t offset = 0;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[lldb] Remove DataExtractor::GetPointer This function is equivalent to GetAddress, but getAddress is also present on the llvm version of the data extractor.
2020-02-18 17:37:04 +08:00
ptr = extractor.GetAddress(&offset);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (m_temporary_allocation == LLDB_INVALID_ADDRESS) {
dump_stream.Printf("Points to process memory:\n");
} else {
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.Printf("Temporary allocation:\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
if (ptr == LLDB_INVALID_ADDRESS) {
dump_stream.Printf(" <could not be be found>\n");
} else {
DataBufferHeap data(m_temporary_allocation_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
map.ReadMemory(data.GetBytes(), m_temporary_allocation,
m_temporary_allocation_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->PutString(dump_stream.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe(IRMemoryMap &map, lldb::addr_t process_address) override {
if (m_temporary_allocation != LLDB_INVALID_ADDRESS) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status free_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
map.Free(m_temporary_allocation, free_error);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_temporary_allocation = LLDB_INVALID_ADDRESS;
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_temporary_allocation_size = 0;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
lldb::VariableSP m_variable_sp;
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
bool m_is_reference = false;
lldb::addr_t m_temporary_allocation = LLDB_INVALID_ADDRESS;
size_t m_temporary_allocation_size = 0;
Made the Materializer not write back variables if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
2014-03-26 06:30:19 +08:00
lldb::DataBufferSP m_original_data;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
Rename Error -> Status. 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-05-12 12:51:55 +08:00
uint32_t Materializer::AddVariable(lldb::VariableSP &variable_sp, Status &err) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
[lldb] Use std::make_unique<> (NFC) Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-25 08:44:33 +08:00
*iter = std::make_unique<EntityVariable>(variable_sp);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityResultVariable : public Materializer::Entity {
public:
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
EntityResultVariable(const CompilerType &type, bool is_program_reference,
bool keep_in_memory,
Materializer::PersistentVariableDelegate *delegate)
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
: Entity(), m_type(type), m_is_program_reference(is_program_reference),
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
m_keep_in_memory(keep_in_memory), m_delegate(delegate) {
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
// Hard-coding to maximum size of a pointer since all results are
// materialized by reference
m_size = 8;
m_alignment = 8;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &err) override {
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!m_is_program_reference) {
if (m_temporary_allocation != LLDB_INVALID_ADDRESS) {
err.SetErrorString("Trying to create a temporary region for the result "
"but one exists");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Unify the ExecutionContextScope computation in Materializer. This is an NFC cleanup for Clang, and a bugfix for the Swift branch. In swift-lldb one target may have multiple scratch TypeSystems, so it is important to pick the one that belongs to the current frame, rather than the one for the current target. <rdar://problem/65001402>
2020-07-09 05:35:02 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
if (!exe_scope)
exe_scope = map.GetBestExecutionContextScope();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Replace auto -> llvm::Optional<uint64_t> This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
2019-01-16 04:33:58 +08:00
llvm::Optional<uint64_t> byte_size = m_type.GetByteSize(exe_scope);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
if (!byte_size) {
Improve materializer error messages to include type names. rdar://79201552
2021-06-12 08:58:05 +08:00
err.SetErrorStringWithFormat("can't get size of type \"%s\"",
m_type.GetTypeName().AsCString());
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign. llvm-svn: 368620
2019-08-13 05:49:54 +08:00
llvm::Optional<size_t> opt_bit_align = m_type.GetTypeBitAlign(exe_scope);
[Symbol] GetTypeBitAlign() should return None in case of failure. Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
2019-08-13 04:03:19 +08:00
if (!opt_bit_align) {
Improve materializer error messages to include type names. rdar://79201552
2021-06-12 08:58:05 +08:00
err.SetErrorStringWithFormat("can't get the alignment of type \"%s\"",
m_type.GetTypeName().AsCString());
[Symbol] GetTypeBitAlign() should return None in case of failure. Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
2019-08-13 04:03:19 +08:00
return;
}
size_t byte_align = (*opt_bit_align + 7) / 8;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status alloc_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const bool zero_memory = true;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_temporary_allocation = map.Malloc(
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
*byte_size, byte_align,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
lldb::ePermissionsReadable | lldb::ePermissionsWritable,
IRMemoryMap::eAllocationPolicyMirror, zero_memory, alloc_error);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
m_temporary_allocation_size = *byte_size;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!alloc_error.Success()) {
err.SetErrorStringWithFormat(
"couldn't allocate a temporary region for the result: %s",
alloc_error.AsCString());
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status pointer_write_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
map.WritePointerToMemory(load_addr, m_temporary_allocation,
pointer_write_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made GetScratchTypeSystemForLanguage return an error if desired. Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
2015-10-03 02:40:30 +08:00
if (!pointer_write_error.Success()) {
err.SetErrorStringWithFormat("couldn't write the address of the "
"temporary region for the result: %s",
pointer_write_error.AsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
}
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Made GetScratchTypeSystemForLanguage return an error if desired. Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
2015-10-03 02:40:30 +08:00
void Dematerialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
lldb::addr_t process_address, lldb::addr_t frame_top,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t frame_bottom, Status &err) override {
Made GetScratchTypeSystemForLanguage return an error if desired. Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
2015-10-03 02:40:30 +08:00
err.Clear();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Unify the ExecutionContextScope computation in Materializer. This is an NFC cleanup for Clang, and a bugfix for the Swift branch. In swift-lldb one target may have multiple scratch TypeSystems, so it is important to pick the one that belongs to the current frame, rather than the one for the current target. <rdar://problem/65001402>
2020-07-09 05:35:02 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
if (!exe_scope)
exe_scope = map.GetBestExecutionContextScope();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Now persistent expression data no longer lives with the Target, but rather with the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
2015-10-01 03:57:57 +08:00
if (!exe_scope) {
err.SetErrorString("Couldn't dematerialize a result variable: invalid "
"execution context scope");
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::addr_t address;
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status read_error;
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Eliminated redundant "constructors" for ClangExpressionVariable. The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. llvm-svn: 249095
2015-10-02 07:07:06 +08:00
map.ReadPointerFromMemory(&address, load_addr, read_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!read_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorString("Couldn't dematerialize a result variable: couldn't "
"read its address");
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
lldb::TargetSP target_sp = exe_scope->CalculateTarget();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
if (!target_sp) {
err.SetErrorString("Couldn't dematerialize a result variable: no target");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[Symbol] Use llvm::Expected when getting TypeSystems Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
2019-07-31 06:12:34 +08:00
auto type_system_or_err =
target_sp->GetScratchTypeSystemForLanguage(m_type.GetMinimumLanguage());
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
[Symbol] Use llvm::Expected when getting TypeSystems Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
2019-07-31 06:12:34 +08:00
if (auto error = type_system_or_err.takeError()) {
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
err.SetErrorStringWithFormat("Couldn't dematerialize a result variable: "
"couldn't get the corresponding type "
"system: %s",
[Symbol] Use llvm::Expected when getting TypeSystems Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
2019-07-31 06:12:34 +08:00
llvm::toString(std::move(error)).c_str());
Fixed a bug in the Materializer where we sent the wrong information to ValueObjectConstResult. <rdar://problem/15101795> llvm-svn: 192264
2013-10-09 10:04:57 +08:00
return;
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
}
Now persistent expression data no longer lives with the Target, but rather with the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
2015-10-01 03:57:57 +08:00
PersistentExpressionState *persistent_state =
[Symbol] Use llvm::Expected when getting TypeSystems Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
2019-07-31 06:12:34 +08:00
type_system_or_err->GetPersistentExpressionState();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!persistent_state) {
err.SetErrorString("Couldn't dematerialize a result variable: "
"corresponding type system doesn't handle persistent "
"variables");
return;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Internal expressions shouldn't increment the result variable numbering. There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate whether the result number should be returned to the pool or not. It got broken when the PersistentExpressionState was refactored. This fixes the issue and provides a test of the behavior. Differential Revision: https://reviews.llvm.org/D76532
2020-03-21 05:59:54 +08:00
ConstString name = m_delegate
? m_delegate->GetName()
: persistent_state->GetNextPersistentVariableName();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::ExpressionVariableSP ret = persistent_state->CreatePersistentVariable(
exe_scope, name, m_type, map.GetByteOrder(), map.GetAddressByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
if (!ret) {
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
err.SetErrorStringWithFormat("couldn't dematerialize a result variable: "
"failed to make persistent variable %s",
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
name.AsCString());
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
return;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
lldb::ProcessSP process_sp =
map.GetBestExecutionContextScope()->CalculateProcess();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
if (m_delegate) {
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_delegate->DidDematerialize(ret);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
bool can_persist =
(m_is_program_reference && process_sp && process_sp->CanJIT() &&
!(address >= frame_bottom && address < frame_top));
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (can_persist && m_keep_in_memory) {
ret->m_live_sp = ValueObjectConstResult::Create(exe_scope, m_type, name,
address, eAddressTypeLoad,
map.GetAddressByteSize());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
ret->ValueUpdated();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[lldb] Use value_or instead of getValueOr (NFC)
2022-06-20 00:12:01 +08:00
const size_t pvar_byte_size = ret->GetByteSize().value_or(0);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
uint8_t *pvar_data = ret->GetValueBytes();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
map.ReadMemory(pvar_data, address, pvar_byte_size, read_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!read_error.Success()) {
err.SetErrorString(
"Couldn't dematerialize a result variable: couldn't read its memory");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!can_persist || !m_keep_in_memory) {
ret->m_flags |= ExpressionVariable::EVNeedsAllocation;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (m_temporary_allocation != LLDB_INVALID_ADDRESS) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status free_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.Free(m_temporary_allocation, free_error);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
} else {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
ret->m_flags |= ExpressionVariable::EVIsLLDBAllocated;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_temporary_allocation = LLDB_INVALID_ADDRESS;
m_temporary_allocation_size = 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
void DumpToLog(IRMemoryMap &map, lldb::addr_t process_address,
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
Log *log) override {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
StreamString dump_stream;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
dump_stream.Printf("0x%" PRIx64 ": EntityResultVariable\n", load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status err;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::addr_t ptr = LLDB_INVALID_ADDRESS;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
{
dump_stream.Printf("Pointer:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
DataBufferHeap data(m_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
DataExtractor extractor(data.GetBytes(), data.GetByteSize(),
map.GetByteOrder(), map.GetAddressByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
[lldb] Fix a couple of use-of-uninit-var errors in Materializer.cpp These were probably not picked up before because they only run when logging is enabled.
2022-01-26 23:46:19 +08:00
lldb::offset_t offset = 0;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[lldb] Remove DataExtractor::GetPointer This function is equivalent to GetAddress, but getAddress is also present on the llvm version of the data extractor.
2020-02-18 17:37:04 +08:00
ptr = extractor.GetAddress(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (m_temporary_allocation == LLDB_INVALID_ADDRESS) {
dump_stream.Printf("Points to process memory:\n");
} else {
dump_stream.Printf("Temporary allocation:\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (ptr == LLDB_INVALID_ADDRESS) {
dump_stream.Printf(" <could not be be found>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
DataBufferHeap data(m_temporary_allocation_size, 0);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
map.ReadMemory(data.GetBytes(), m_temporary_allocation,
m_temporary_allocation_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
}
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->PutString(dump_stream.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Wipe(IRMemoryMap &map, lldb::addr_t process_address) override {
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!m_keep_in_memory && m_temporary_allocation != LLDB_INVALID_ADDRESS) {
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status free_error;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
map.Free(m_temporary_allocation, free_error);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_temporary_allocation = LLDB_INVALID_ADDRESS;
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_temporary_allocation_size = 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
Removed a bunch of dependencies of Materializer on ClangUserExpression. Instead we now just generically use UserExpression. llvm-svn: 248842
2015-09-30 06:52:50 +08:00
CompilerType m_type;
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
bool m_is_program_reference;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
bool m_keep_in_memory;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
lldb::addr_t m_temporary_allocation = LLDB_INVALID_ADDRESS;
size_t m_temporary_allocation_size = 0;
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
Materializer::PersistentVariableDelegate *m_delegate;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
uint32_t Materializer::AddResultVariable(const CompilerType &type,
bool is_program_reference,
bool keep_in_memory,
PersistentVariableDelegate *delegate,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status &err) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
[lldb] Use std::make_unique<> (NFC) Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-25 08:44:33 +08:00
*iter = std::make_unique<EntityResultVariable>(type, is_program_reference,
keep_in_memory, delegate);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntitySymbol : public Materializer::Entity {
public:
EntitySymbol(const Symbol &symbol) : Entity(), m_symbol(symbol) {
// Hard-coding to maximum size of a symbol
m_size = 8;
m_alignment = 8;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntitySymbol::Materialize [address = 0x%" PRIx64
", m_symbol = %s]",
(uint64_t)load_addr, m_symbol.GetName().AsCString());
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const Address sym_address = m_symbol.GetAddress();
Unify the ExecutionContextScope computation in Materializer. This is an NFC cleanup for Clang, and a bugfix for the Swift branch. In swift-lldb one target may have multiple scratch TypeSystems, so it is important to pick the one that belongs to the current frame, rather than the one for the current target. <rdar://problem/65001402>
2020-07-09 05:35:02 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
if (!exe_scope)
exe_scope = map.GetBestExecutionContextScope();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Resubmitting 240466 after fixing the linux test suite failures. A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
2015-06-26 05:46:34 +08:00
lldb::TargetSP target_sp;
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
if (exe_scope)
target_sp = map.GetBestExecutionContextScope()->CalculateTarget();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
if (!target_sp) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't resolve symbol %s because there is no target",
m_symbol.GetName().AsCString());
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
lldb::addr_t resolved_address = sym_address.GetLoadAddress(target_sp.get());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
if (resolved_address == LLDB_INVALID_ADDRESS)
resolved_address = sym_address.GetFileAddress();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status pointer_write_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, resolved_address, pointer_write_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
if (!pointer_write_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't write the address of symbol %s: %s",
m_symbol.GetName().AsCString(), pointer_write_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Dematerialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
lldb::addr_t process_address, lldb::addr_t frame_top,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t frame_bottom, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntitySymbol::Dematerialize [address = 0x%" PRIx64
", m_symbol = %s]",
(uint64_t)load_addr, m_symbol.GetName().AsCString());
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
// no work needs to be done
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog(IRMemoryMap &map, lldb::addr_t process_address,
Log *log) override {
StreamString dump_stream;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status err;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.Printf("0x%" PRIx64 ": EntitySymbol (%s)\n", load_addr,
m_symbol.GetName().AsCString());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
{
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.Printf("Pointer:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
DataBufferHeap data(m_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->PutString(dump_stream.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Wipe(IRMemoryMap &map, lldb::addr_t process_address) override {}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
Symbol m_symbol;
};
Rename Error -> Status. 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-05-12 12:51:55 +08:00
uint32_t Materializer::AddSymbol(const Symbol &symbol_sp, Status &err) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
[lldb] Use std::make_unique<> (NFC) Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-25 08:44:33 +08:00
*iter = std::make_unique<EntitySymbol>(symbol_sp);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityRegister : public Materializer::Entity {
public:
EntityRegister(const RegisterInfo &register_info)
: Entity(), m_register_info(register_info) {
// Hard-coding alignment conservatively
m_size = m_register_info.byte_size;
m_alignment = m_register_info.byte_size;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityRegister::Materialize [address = 0x%" PRIx64
", m_register_info = %s]",
(uint64_t)load_addr, m_register_info.name);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
RegisterValue reg_value;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!frame_sp.get()) {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
err.SetErrorStringWithFormat(
"couldn't materialize register %s without a stack frame",
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
m_register_info.name);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
}
lldb::RegisterContextSP reg_context_sp = frame_sp->GetRegisterContext();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
if (!reg_context_sp->ReadRegister(&m_register_info, reg_value)) {
err.SetErrorStringWithFormat("couldn't read the value of register %s",
m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
DataExtractor register_data;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!reg_value.GetData(register_data)) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for register %s",
m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (register_data.GetByteSize() != m_register_info.byte_size) {
err.SetErrorStringWithFormat(
"data for register %s had size %llu but we expected %llu",
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
m_register_info.name, (unsigned long long)register_data.GetByteSize(),
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
(unsigned long long)m_register_info.byte_size);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Use std::make_shared in LLDB (NFC) 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
2019-02-12 07:13:08 +08:00
m_register_contents = std::make_shared<DataBufferHeap>(
register_data.GetDataStart(), register_data.GetByteSize());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status write_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
map.WriteMemory(load_addr, register_data.GetDataStart(),
register_data.GetByteSize(), write_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!write_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't write the contents of register %s: %s",
m_register_info.name, write_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Dematerialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
lldb::addr_t process_address, lldb::addr_t frame_top,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t frame_bottom, Status &err) override {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
Log *log = GetLog(LLDBLog::Expressions);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (log) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"EntityRegister::Dematerialize [address = 0x%" PRIx64
", m_register_info = %s]",
(uint64_t)load_addr, m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status extract_error;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
DataExtractor register_data;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!frame_sp.get()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat(
"couldn't dematerialize register %s without a stack frame",
m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
lldb::RegisterContextSP reg_context_sp = frame_sp->GetRegisterContext();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.GetMemoryData(register_data, load_addr, m_register_info.byte_size,
extract_error);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!extract_error.Success()) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for register %s: %s",
m_register_info.name,
extract_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
if (!memcmp(register_data.GetDataStart(), m_register_contents->GetBytes(),
register_data.GetByteSize())) {
// No write required, and in particular we avoid errors if the register
// wasn't writable
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
m_register_contents.reset();
return;
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
m_register_contents.reset();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
[lldb/Utility] Add unit tests for RegisterValue::GetScalarValue Buggy cases are commented out. Also sneak in a modernization of a RegisterValue constructor.
2020-09-07 15:33:58 +08:00
RegisterValue register_value(register_data.GetData(),
register_data.GetByteOrder());
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!reg_context_sp->WriteRegister(&m_register_info, register_value)) {
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the value of register %s",
m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void DumpToLog(IRMemoryMap &map, lldb::addr_t process_address,
Log *log) override {
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
StreamString dump_stream;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status err;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.Printf("0x%" PRIx64 ": EntityRegister (%s)\n", load_addr,
m_register_info.name);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
{
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.Printf("Value:\n");
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
DataBufferHeap data(m_size, 0);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (!err.Success()) {
dump_stream.Printf(" <could not be read>\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16,
load_addr);
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
dump_stream.PutChar('\n');
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->PutString(dump_stream.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
void Wipe(IRMemoryMap &map, lldb::addr_t process_address) override {}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
RegisterInfo m_register_info;
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
lldb::DataBufferSP m_register_contents;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
uint32_t Materializer::AddRegister(const RegisterInfo &register_info,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
Status &err) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
[lldb] Use std::make_unique<> (NFC) Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-25 08:44:33 +08:00
*iter = std::make_unique<EntityRegister>(register_info);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Materializer::~Materializer() {
DematerializerSP dematerializer_sp = m_dematerializer_wp.lock();
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
if (dematerializer_sp)
dematerializer_sp->Wipe();
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Materializer::DematerializerSP
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
Materializer::Materialize(lldb::StackFrameSP &frame_sp, IRMemoryMap &map,
Rename Error -> Status. 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-05-12 12:51:55 +08:00
lldb::addr_t process_address, Status &error) {
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
if (!exe_scope)
exe_scope = map.GetBestExecutionContextScope();
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
DematerializerSP dematerializer_sp = m_dematerializer_wp.lock();
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
if (dematerializer_sp) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't materialize: already materialized");
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
DematerializerSP ret(
new Dematerializer(*this, frame_sp, map, process_address));
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!exe_scope) {
error.SetErrorToGenericError();
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
error.SetErrorString("Couldn't materialize: target doesn't exist");
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
for (EntityUP &entity_up : m_entities) {
entity_up->Materialize(frame_sp, map, process_address, error);
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
if (!error.Success())
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
return DematerializerSP();
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
if (Log *log = GetLog(LLDBLog::Expressions)) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(
log,
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
"Materializer::Materialize (frame_sp = %p, process_address = 0x%" PRIx64
") materialized:",
static_cast<void *>(frame_sp.get()), process_address);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
for (EntityUP &entity_up : m_entities)
entity_up->DumpToLog(map, process_address, log);
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_dematerializer_wp = ret;
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
return ret;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Rename Error -> Status. 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-05-12 12:51:55 +08:00
void Materializer::Dematerializer::Dematerialize(Status &error,
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
lldb::addr_t frame_bottom,
lldb::addr_t frame_top) {
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
lldb::StackFrameSP frame_sp;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Fixed a problem with materialization and dematerialization of registers that caused conditional breakpoint expressions not to work properly. Also added a testcase. <rdar://problem/14129252> llvm-svn: 184451
2013-06-21 02:42:16 +08:00
lldb::ThreadSP thread_sp = m_thread_wp.lock();
if (thread_sp)
frame_sp = thread_sp->GetFrameWithStackID(m_stack_id);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Unify the ExecutionContextScope computation in Materializer. This is an NFC cleanup for Clang, and a bugfix for the Swift branch. In swift-lldb one target may have multiple scratch TypeSystems, so it is important to pick the one that belongs to the current frame, rather than the one for the current target. <rdar://problem/65001402>
2020-07-09 05:35:02 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
if (!exe_scope)
exe_scope = m_map->GetBestExecutionContextScope();
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
if (!IsValid()) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't dematerialize: invalid dematerializer");
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!exe_scope) {
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
error.SetErrorToGenericError();
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
error.SetErrorString("Couldn't dematerialize: target is gone");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
} else {
[lldb] Convert "LLDB" log channel to the new API
2022-01-31 22:57:48 +08:00
if (Log *log = GetLog(LLDBLog::Expressions)) {
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) 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-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"Materializer::Dematerialize (frame_sp = %p, process_address "
"= 0x%" PRIx64 ") about to dematerialize:",
static_cast<void *>(frame_sp.get()), m_process_address);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
for (EntityUP &entity_up : m_materializer->m_entities)
entity_up->DumpToLog(*m_map, m_process_address, log);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
for (EntityUP &entity_up : m_materializer->m_entities) {
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
entity_up->Dematerialize(frame_sp, *m_map, m_process_address, frame_top,
frame_bottom, error);
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
if (!error.Success())
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-07 04:57:50 +08:00
}
sweep up -Wformat warnings from gcc 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
2014-04-04 12:06:10 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Wipe();
}
void Materializer::Dematerializer::Wipe() {
if (!IsValid())
return;
Register value is not necessarily scalar. Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
2016-02-27 06:12:35 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
for (EntityUP &entity_up : m_materializer->m_entities) {
entity_up->Wipe(*m_map, m_process_address);
}
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
m_materializer = nullptr;
m_map = nullptr;
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_process_address = LLDB_INVALID_ADDRESS;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Add PersistentVariableDelegate to handle language-specific dematerialization. The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
2015-10-03 17:09:01 +08:00
Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes. llvm-svn: 251309
2015-10-27 01:00:13 +08:00
Materializer::PersistentVariableDelegate::~PersistentVariableDelegate() =
default;