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/IRMemoryMap.cpp

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

847 lines
26 KiB
C++
Raw Normal View History

Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
//===-- IRMemoryMap.cpp -----------------------------------------*- C++ -*-===//
//
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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
//
//===----------------------------------------------------------------------===//
#include "lldb/Expression/IRMemoryMap.h"
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
#include "lldb/Target/MemoryRegionInfo.h"
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
#include "lldb/Target/Process.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/Target/Target.h"
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 09:30:05 +08:00
#include "lldb/Utility/DataBufferHeap.h"
#include "lldb/Utility/DataExtractor.h"
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
#include "lldb/Utility/LLDBAssert.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/Scalar.h"
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
#include "lldb/Utility/Status.h"
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
using namespace lldb_private;
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
IRMemoryMap::IRMemoryMap(lldb::TargetSP target_sp) : m_target_wp(target_sp) {
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 (target_sp)
m_process_wp = target_sp->GetProcessSP();
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
IRMemoryMap::~IRMemoryMap() {
lldb::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (process_sp) {
Added a per-process cache for reserved memory regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
2013-05-17 01:30:37 +08:00
AllocationMap::iterator iter;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +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;
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
while ((iter = m_allocations.begin()) != m_allocations.end()) {
Added a per-process cache for reserved memory regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
2013-05-17 01:30:37 +08:00
err.Clear();
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
if (iter->second.m_leak)
m_allocations.erase(iter);
*** 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
Free(iter->first, err);
*** 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
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
lldb::addr_t IRMemoryMap::FindSpace(size_t size) {
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// The FindSpace algorithm's job is to find a region of memory that the
// underlying process is unlikely to be using.
*** 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
//
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// The memory returned by this function will never be written to. The only
// point is that it should not shadow process memory if possible, so that
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
// expressions processing real values from the process do not use the wrong
// data.
*** 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
//
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// If the process can in fact allocate memory (CanJIT() lets us know this)
// then this can be accomplished just be allocating memory in the inferior.
// Then no guessing is required.
*** 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
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
lldb::TargetSP target_sp = m_target_wp.lock();
lldb::ProcessSP process_sp = m_process_wp.lock();
*** 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 lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
const bool process_is_alive = process_sp && process_sp->IsAlive();
*** 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
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
lldb::addr_t ret = LLDB_INVALID_ADDRESS;
Dont' use a random probe & alloc strategy for the IRMemoryMap. The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
2014-07-10 00:42:27 +08:00
if (size == 0)
return ret;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
if (process_is_alive && process_sp->CanJIT()) {
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;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
ret = process_sp->AllocateMemory(size, lldb::ePermissionsReadable |
lldb::ePermissionsWritable,
alloc_error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
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
if (!alloc_error.Success())
return LLDB_INVALID_ADDRESS;
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
else
return ret;
}
*** 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// At this point we know that we need to hunt.
*** 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
//
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// First, go to the end of the existing allocations we've made if there are
// any allocations. Otherwise start at the beginning of 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
if (m_allocations.empty()) {
ret = 0x0;
} else {
auto back = m_allocations.rbegin();
lldb::addr_t addr = back->first;
size_t alloc_size = back->second.m_size;
ret = llvm::alignTo(addr + alloc_size, 4096);
*** 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
}
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// Now, if it's possible to use the GetMemoryRegionInfo API to detect mapped
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
// regions, walk forward through memory until a region is found that has
// adequate space for our allocation.
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
if (process_is_alive) {
const uint64_t end_of_memory = process_sp->GetAddressByteSize() == 8
? 0xffffffffffffffffull
: 0xffffffffull;
*** 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
lldbassert(process_sp->GetAddressByteSize() == 4 ||
end_of_memory != 0xffffffffull);
*** 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
MemoryRegionInfo region_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 = process_sp->GetMemoryRegionInfo(ret, region_info);
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
if (err.Success()) {
while (true) {
if (region_info.GetReadable() != MemoryRegionInfo::OptionalBool::eNo ||
region_info.GetWritable() != MemoryRegionInfo::OptionalBool::eNo ||
region_info.GetExecutable() !=
MemoryRegionInfo::OptionalBool::eNo) {
if (region_info.GetRange().GetRangeEnd() - 1 >= end_of_memory) {
ret = LLDB_INVALID_ADDRESS;
*** 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
break;
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
} else {
ret = region_info.GetRange().GetRangeEnd();
}
} else if (ret + size < region_info.GetRange().GetRangeEnd()) {
return ret;
} else {
// ret stays the same. We just need to walk a bit further.
}
*** 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
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
err = process_sp->GetMemoryRegionInfo(
region_info.GetRange().GetRangeEnd(), region_info);
if (err.Fail()) {
Silence some -Wstring-conversion warnings lldbassert(!"foo") -> lldbassert(0 && "foo") In one case, this actually detected a logic error in the assertion (missing !). llvm-svn: 291102
2017-01-05 21:18:42 +08:00
lldbassert(0 && "GetMemoryRegionInfo() succeeded, then failed");
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
ret = LLDB_INVALID_ADDRESS;
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
}
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +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
}
Dont' use a random probe & alloc strategy for the IRMemoryMap. The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
2014-07-10 00:42:27 +08:00
// We've tried our algorithm, and it didn't work. Now we have to reset back
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
// to the end of the allocations we've already reported, or use a 'sensible'
Dont' use a random probe & alloc strategy for the IRMemoryMap. The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
2014-07-10 00:42:27 +08:00
// default if this is our first allocation.
*** 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
Dont' use a random probe & alloc strategy for the IRMemoryMap. The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
2014-07-10 00:42:27 +08:00
if (m_allocations.empty()) {
uint32_t address_byte_size = GetAddressByteSize();
Update for llvm change. NFC. llvm-svn: 258080
2016-01-19 04:57:54 +08:00
if (address_byte_size != UINT32_MAX) {
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
switch (address_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
case 8:
Update for llvm change. NFC. llvm-svn: 258080
2016-01-19 04:57:54 +08:00
ret = 0xffffffff00000000ull;
*** 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
break;
Update for llvm change. NFC. llvm-svn: 258080
2016-01-19 04:57:54 +08:00
case 4:
ret = 0xee000000ull;
*** 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
break;
default:
break;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +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
} else {
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
auto back = m_allocations.rbegin();
Dont' use a random probe & alloc strategy for the IRMemoryMap. The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
2014-07-10 00:42:27 +08:00
lldb::addr_t addr = back->first;
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
size_t alloc_size = back->second.m_size;
ret = llvm::alignTo(addr + alloc_size, 4096);
*** 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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
return ret;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
IRMemoryMap::AllocationMap::iterator
IRMemoryMap::FindAllocation(lldb::addr_t addr, size_t size) {
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 (addr == LLDB_INVALID_ADDRESS)
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return m_allocations.end();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
AllocationMap::iterator iter = m_allocations.lower_bound(addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (iter == m_allocations.end() || iter->first > addr) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (iter == m_allocations.begin())
return m_allocations.end();
*** 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
iter--;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
if (iter->first <= addr && iter->first + iter->second.m_size >= addr + size)
return iter;
return m_allocations.end();
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
}
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
bool IRMemoryMap::IntersectsAllocation(lldb::addr_t addr, size_t size) const {
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
if (addr == LLDB_INVALID_ADDRESS)
return 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
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
AllocationMap::const_iterator iter = m_allocations.lower_bound(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
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
// Since we only know that the returned interval begins at a location greater
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
// than or equal to where the given interval begins, it's possible that the
// given interval intersects either the returned interval or the previous
// interval. Thus, we need to check both. Note that we only need to check
// these two intervals. Since all intervals are disjoint it is not possible
// that an adjacent interval does not intersect, but a non-adjacent interval
// does intersect.
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
if (iter != m_allocations.end()) {
Fix silly compilation error. llvm-svn: 211728
2014-06-26 02:40:58 +08:00
if (AllocationsIntersect(addr, size, iter->second.m_process_start,
iter->second.m_size))
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
return true;
*** 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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (iter != m_allocations.begin()) {
*** 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
--iter;
Fix silly compilation error. llvm-svn: 211728
2014-06-26 02:40:58 +08:00
if (AllocationsIntersect(addr, size, iter->second.m_process_start,
iter->second.m_size))
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
return true;
*** 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
}
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
return false;
}
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
bool IRMemoryMap::AllocationsIntersect(lldb::addr_t addr1, size_t size1,
lldb::addr_t addr2, size_t size2) {
// Given two half open intervals [A, B) and [X, Y), the only 6 permutations
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
// that satisfy A<B and X<Y are the following:
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
// A B X Y
// A X B Y (intersects)
// A X Y B (intersects)
// X A B Y (intersects)
// X A Y B (intersects)
// X Y A B
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
// The first is B <= X, and the last is Y <= A. So the condition is !(B <= X
// || Y <= A)), or (X < B && A < Y)
Fix a bug in the IRMemoryMap which generated bogus allocations. Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
2014-06-26 02:37:19 +08:00
return (addr2 < (addr1 + size1)) && (addr1 < (addr2 + size2));
}
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::ByteOrder IRMemoryMap::GetByteOrder() {
lldb::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (process_sp)
return process_sp->GetByteOrder();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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::TargetSP target_sp = m_target_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (target_sp)
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
return target_sp->GetArchitecture().GetByteOrder();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
return lldb::eByteOrderInvalid;
}
uint32_t IRMemoryMap::GetAddressByteSize() {
lldb::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (process_sp)
return process_sp->GetAddressByteSize();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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::TargetSP target_sp = m_target_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (target_sp)
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
return target_sp->GetArchitecture().GetAddressByteSize();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
return UINT32_MAX;
}
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
ExecutionContextScope *IRMemoryMap::GetBestExecutionContextScope() const {
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::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (process_sp)
return process_sp.get();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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::TargetSP target_sp = m_target_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (target_sp)
return target_sp.get();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
[lldb] NFC modernize codebase with modernize-use-nullptr Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
2019-05-23 19:14:47 +08:00
return nullptr;
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
}
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
IRMemoryMap::Allocation::Allocation(lldb::addr_t process_alloc,
lldb::addr_t process_start, size_t size,
uint32_t permissions, uint8_t alignment,
Initialize m_leak member variable. llvm-svn: 187822
2013-08-07 06:21:08 +08:00
AllocationPolicy policy)
: m_process_alloc(process_alloc), m_process_start(process_start),
[IRMemoryMap] Shrink Allocation and make it move-only (NFC) Profiling data show that Allocation::operator= is hot (see the data attached to the Phab review). Reorder a few fields within Allocation to avoid implicit structure padding and shrink the structure. This should make copies a bit cheaper. Also, given that an Allocation contains a std::vector (by way of DataBufferHeap), it's preferable to make it move-only instead of permitting expensive copies. As an added benefit this allows us to have a single Allocation constructor instead of two. Differential Revision: https://reviews.llvm.org/D50271 llvm-svn: 339290
2018-08-09 05:26:49 +08:00
m_size(size), m_policy(policy), m_leak(false), m_permissions(permissions),
m_alignment(alignment) {
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
switch (policy) {
default:
[IRMemoryMap] Fix -Wimplicit-fallthrough in -DLLVM_ENABLE_ASSERTIONS=off build llvm-svn: 358249
2019-04-12 10:38:17 +08:00
llvm_unreachable("Invalid AllocationPolicy");
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
case eAllocationPolicyHostOnly:
[IRMemoryMap] Avoid redundant zero-init in the Allocation constructor (NFC) In the lldb-bench/arithmetic benchmark, 1.7% of the total running time is spent zero-initializing a std::vector that has already been zeroed. llvm-svn: 339051
2018-08-07 04:13:52 +08:00
case eAllocationPolicyMirror:
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
m_data.SetByteSize(size);
break;
case eAllocationPolicyProcessOnly:
break;
}
}
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::addr_t IRMemoryMap::Malloc(size_t size, uint8_t alignment,
uint32_t permissions, AllocationPolicy policy,
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
bool zero_memory, Status &error) {
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
lldb_private::Log *log(
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
*** 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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
lldb::ProcessSP process_sp;
lldb::addr_t allocation_address = LLDB_INVALID_ADDRESS;
lldb::addr_t aligned_address = LLDB_INVALID_ADDRESS;
*** 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
Change Malloc to request an aligned memory size. This fixes a problem on Linux where allocated memory would get overun in some use cases (ie. in TestExprs2.py). llvm-svn: 180614
2013-04-27 01:48:01 +08:00
size_t allocation_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
[IRMemoryMap] Fix the alignment adjustment in Malloc This prevents Malloc from allocating the same chunk of memory twice, as a byproduct of an alignment adjustment which gave the client access to unallocated memory. Prior to this patch, the newly-added test failed with: $ lldb-test ir-memory-map ... ir-memory-map-overlap1.test ... Command: malloc(size=64, alignment=32) Malloc: address = 0x1000cd080 Command: malloc(size=64, alignment=8) Malloc: address = 0x1000cd0b0 Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0) Differential Revision: https://reviews.llvm.org/D47551 llvm-svn: 333697
2018-06-01 06:08:59 +08:00
if (size == 0) {
// FIXME: Malloc(0) should either return an invalid address or assert, in
// order to cut down on unnecessary allocations.
Change Malloc to request an aligned memory size. This fixes a problem on Linux where allocated memory would get overun in some use cases (ie. in TestExprs2.py). llvm-svn: 180614
2013-04-27 01:48:01 +08:00
allocation_size = alignment;
[IRMemoryMap] Fix the alignment adjustment in Malloc This prevents Malloc from allocating the same chunk of memory twice, as a byproduct of an alignment adjustment which gave the client access to unallocated memory. Prior to this patch, the newly-added test failed with: $ lldb-test ir-memory-map ... ir-memory-map-overlap1.test ... Command: malloc(size=64, alignment=32) Malloc: address = 0x1000cd080 Command: malloc(size=64, alignment=8) Malloc: address = 0x1000cd0b0 Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0) Differential Revision: https://reviews.llvm.org/D47551 llvm-svn: 333697
2018-06-01 06:08:59 +08:00
} else {
// Round up the requested size to an aligned value.
allocation_size = llvm::alignTo(size, alignment);
// The process page cache does not see the requested alignment. We can't
// assume its result will be any more than 1-byte aligned. To work around
// this, request `alignment - 1` additional bytes.
allocation_size += alignment - 1;
}
*** 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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
switch (policy) {
*** 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
default:
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't malloc: invalid allocation policy");
return LLDB_INVALID_ADDRESS;
case eAllocationPolicyHostOnly:
allocation_address = FindSpace(allocation_size);
if (allocation_address == LLDB_INVALID_ADDRESS) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't malloc: address space is full");
return LLDB_INVALID_ADDRESS;
*** 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
}
break;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyMirror:
process_sp = m_process_wp.lock();
[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,
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
"IRMemoryMap::%s process_sp=0x%" PRIxPTR
[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
", process_sp->CanJIT()=%s, process_sp->IsAlive()=%s",
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
__FUNCTION__, reinterpret_cast<uintptr_t>(process_sp.get()),
[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
process_sp && process_sp->CanJIT() ? "true" : "false",
process_sp && process_sp->IsAlive() ? "true" : "false");
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (process_sp && process_sp->CanJIT() && process_sp->IsAlive()) {
if (!zero_memory)
allocation_address =
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
process_sp->AllocateMemory(allocation_size, permissions, 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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
allocation_address =
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
process_sp->CallocateMemory(allocation_size, permissions, 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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
return LLDB_INVALID_ADDRESS;
*** 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 {
[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,
"IRMemoryMap::%s switching to eAllocationPolicyHostOnly "
"due to failed condition (see previous expr log message)",
__FUNCTION__);
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
policy = eAllocationPolicyHostOnly;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
allocation_address = FindSpace(allocation_size);
if (allocation_address == LLDB_INVALID_ADDRESS) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't malloc: address space is full");
return LLDB_INVALID_ADDRESS;
*** 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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
break;
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
case eAllocationPolicyProcessOnly:
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
process_sp = m_process_wp.lock();
if (process_sp) {
Fixed a problem in the expression parser that caused the IR interpreter not to work if the process had finished running. <rdar://problem/14124301> llvm-svn: 184125
2013-06-18 05:19:31 +08:00
if (process_sp->CanJIT() && process_sp->IsAlive()) {
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
if (!zero_memory)
allocation_address =
process_sp->AllocateMemory(allocation_size, permissions, error);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
else
allocation_address =
process_sp->CallocateMemory(allocation_size, permissions, error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
return LLDB_INVALID_ADDRESS;
*** 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 {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString(
Made IRMemoryMap::FindSpace a little cleverer, and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
2013-04-19 09:51:24 +08:00
"Couldn't malloc: process doesn't support allocating memory");
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return LLDB_INVALID_ADDRESS;
*** 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 {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
error.SetErrorString("Couldn't malloc: process doesn't exist, and this "
Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe. Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
2016-06-10 04:22:25 +08:00
"memory must be in the process");
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return LLDB_INVALID_ADDRESS;
*** 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
}
break;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
lldb::addr_t mask = alignment - 1;
aligned_address = (allocation_address + mask) & (~mask);
[IRMemoryMap] Shrink Allocation and make it move-only (NFC) Profiling data show that Allocation::operator= is hot (see the data attached to the Phab review). Reorder a few fields within Allocation to avoid implicit structure padding and shrink the structure. This should make copies a bit cheaper. Also, given that an Allocation contains a std::vector (by way of DataBufferHeap), it's preferable to make it move-only instead of permitting expensive copies. As an added benefit this allows us to have a single Allocation constructor instead of two. Differential Revision: https://reviews.llvm.org/D50271 llvm-svn: 339290
2018-08-09 05:26:49 +08:00
m_allocations.emplace(
std::piecewise_construct, std::forward_as_tuple(aligned_address),
std::forward_as_tuple(allocation_address, aligned_address,
allocation_size, permissions, alignment, policy));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem in IRMemoryMap where the flag to zero out memory was ignored. llvm-svn: 272320
2016-06-10 06:22:40 +08:00
if (zero_memory) {
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;
Fixed a problem in IRMemoryMap where the flag to zero out memory was ignored. llvm-svn: 272320
2016-06-10 06:22:40 +08:00
std::vector<uint8_t> zero_buf(size, 0);
WriteMemory(aligned_address, zero_buf.data(), size, write_error);
}
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
if (log) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
const char *policy_string;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
switch (policy) {
default:
policy_string = "<invalid policy>";
break;
case eAllocationPolicyHostOnly:
policy_string = "eAllocationPolicyHostOnly";
break;
case eAllocationPolicyProcessOnly:
policy_string = "eAllocationPolicyProcessOnly";
break;
case eAllocationPolicyMirror:
policy_string = "eAllocationPolicyMirror";
break;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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,
"IRMemoryMap::Malloc (%" PRIu64 ", 0x%" PRIx64 ", 0x%" PRIx64
", %s) -> 0x%" PRIx64,
(uint64_t)allocation_size, (uint64_t)alignment,
(uint64_t)permissions, policy_string, aligned_address);
*** 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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return aligned_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
void IRMemoryMap::Leak(lldb::addr_t process_address, Status &error) {
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
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
AllocationMap::iterator iter = m_allocations.find(process_address);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
if (iter == m_allocations.end()) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't leak: allocation doesn't exist");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
Allocation &allocation = iter->second;
allocation.m_leak = true;
}
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 IRMemoryMap::Free(lldb::addr_t process_address, Status &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
AllocationMap::iterator iter = m_allocations.find(process_address);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (iter == m_allocations.end()) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't free: allocation doesn't exist");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a per-process cache for reserved memory regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
2013-05-17 01:30:37 +08:00
Allocation &allocation = iter->second;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
switch (allocation.m_policy) {
default:
case eAllocationPolicyHostOnly: {
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
lldb::ProcessSP process_sp = m_process_wp.lock();
if (process_sp) {
Fixed a problem in the expression parser that caused the IR interpreter not to work if the process had finished running. <rdar://problem/14124301> llvm-svn: 184125
2013-06-18 05:19:31 +08:00
if (process_sp->CanJIT() && process_sp->IsAlive())
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
process_sp->DeallocateMemory(
allocation.m_process_alloc); // FindSpace allocated this for real
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
break;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyMirror:
case eAllocationPolicyProcessOnly: {
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
lldb::ProcessSP process_sp = m_process_wp.lock();
Added a per-process cache for reserved memory regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
2013-05-17 01:30:37 +08:00
if (process_sp)
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
process_sp->DeallocateMemory(allocation.m_process_alloc);
*** 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
}
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (lldb_private::Log *log =
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_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,
"IRMemoryMap::Free (0x%" PRIx64 ") freed [0x%" PRIx64
"..0x%" PRIx64 ")",
(uint64_t)process_address, iter->second.m_process_start,
iter->second.m_process_start + iter->second.m_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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_allocations.erase(iter);
}
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
2015-07-14 18:56:58 +08:00
bool IRMemoryMap::GetAllocSize(lldb::addr_t address, size_t &size) {
AllocationMap::iterator iter = FindAllocation(address, size);
if (iter == m_allocations.end())
return false;
Allocation &al = iter->second;
if (address > (al.m_process_start + al.m_size)) {
size = 0;
return false;
}
if (address > al.m_process_start) {
int dif = address - al.m_process_start;
size = al.m_size - dif;
return true;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
size = al.m_size;
return true;
*** 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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
void IRMemoryMap::WriteMemory(lldb::addr_t process_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
const uint8_t *bytes, size_t size,
Status &error) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
AllocationMap::iterator iter = FindAllocation(process_address, size);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
if (iter == m_allocations.end()) {
lldb::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (process_sp) {
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
process_sp->WriteMemory(process_address, bytes, size, error);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write: no allocation contains the target "
"range and the process doesn't exist");
*** 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;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Allocation &allocation = iter->second;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
uint64_t offset = process_address - allocation.m_process_start;
lldb::ProcessSP process_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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
switch (allocation.m_policy) {
default:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write: invalid allocation policy");
*** 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;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyHostOnly:
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write: data buffer is empty");
*** 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;
}
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
::memcpy(allocation.m_data.GetBytes() + offset, bytes, 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
break;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyMirror:
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write: data buffer is empty");
*** 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;
}
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
::memcpy(allocation.m_data.GetBytes() + offset, bytes, size);
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
process_sp = m_process_wp.lock();
Added a per-process cache for reserved memory regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
2013-05-17 01:30:37 +08:00
if (process_sp) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
process_sp->WriteMemory(process_address, bytes, size, error);
if (!error.Success())
return;
}
break;
case eAllocationPolicyProcessOnly:
process_sp = m_process_wp.lock();
if (process_sp) {
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
process_sp->WriteMemory(process_address, bytes, size, error);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
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
break;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (lldb_private::Log *log =
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_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,
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
"IRMemoryMap::WriteMemory (0x%" PRIx64 ", 0x%" PRIxPTR
[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
", 0x%" PRId64 ") went to [0x%" PRIx64 "..0x%" PRIx64 ")",
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
(uint64_t)process_address, reinterpret_cast<uintptr_t>(bytes), (uint64_t)size,
[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
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start +
(uint64_t)allocation.m_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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +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 IRMemoryMap::WriteScalarToMemory(lldb::addr_t process_address,
Scalar &scalar, size_t size,
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 &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
*** 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 (size == UINT32_MAX)
size = scalar.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
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 (size > 0) {
uint8_t buf[32];
const size_t mem_size =
scalar.GetAsMemoryData(buf, size, GetByteOrder(), error);
if (mem_size > 0) {
return WriteMemory(process_address, buf, mem_size, error);
} else {
error.SetErrorToGenericError();
error.SetErrorString(
"Couldn't write scalar: failed to get scalar as memory data");
}
} else {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write scalar: its size was zero");
}
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
void IRMemoryMap::WritePointerToMemory(lldb::addr_t process_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
lldb::addr_t address, Status &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
Scalar scalar(address);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
WriteScalarToMemory(process_address, scalar, GetAddressByteSize(), error);
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
void IRMemoryMap::ReadMemory(uint8_t *bytes, lldb::addr_t process_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
size_t size, Status &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
AllocationMap::iterator iter = FindAllocation(process_address, size);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
if (iter == m_allocations.end()) {
lldb::ProcessSP process_sp = m_process_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
if (process_sp) {
process_sp->ReadMemory(process_address, bytes, size, error);
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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
lldb::TargetSP target_sp = m_target_wp.lock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
if (target_sp) {
Address absolute_address(process_address);
target_sp->ReadMemory(absolute_address, false, bytes, size, error);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: no allocation contains the target "
"range, and neither the process nor the target exist");
*** 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;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Allocation &allocation = iter->second;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hardened against reads in the IRMemoryMap that exceed the bounds of the backing memory. <rdar://problem/16088322> llvm-svn: 202899
2014-03-05 05:56:11 +08:00
uint64_t offset = process_address - allocation.m_process_start;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (offset > allocation.m_size) {
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: data is not in the allocation");
*** 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;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
lldb::ProcessSP process_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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
switch (allocation.m_policy) {
default:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: invalid allocation policy");
*** 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;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyHostOnly:
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: data buffer is empty");
*** 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;
}
Hardened against reads in the IRMemoryMap that exceed the bounds of the backing memory. <rdar://problem/16088322> llvm-svn: 202899
2014-03-05 05:56:11 +08:00
if (allocation.m_data.GetByteSize() < offset + size) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
Hardened against reads in the IRMemoryMap that exceed the bounds of the backing memory. <rdar://problem/16088322> llvm-svn: 202899
2014-03-05 05:56:11 +08:00
error.SetErrorString("Couldn't read: not enough underlying data");
*** 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;
}
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
::memcpy(bytes, allocation.m_data.GetBytes() + offset, 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
break;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyMirror:
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
process_sp = m_process_wp.lock();
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (process_sp) {
process_sp->ReadMemory(process_address, bytes, size, error);
if (!error.Success())
*** 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 {
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: data buffer is empty");
*** 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;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
::memcpy(bytes, allocation.m_data.GetBytes() + offset, 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
}
break;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
case eAllocationPolicyProcessOnly:
process_sp = m_process_wp.lock();
if (process_sp) {
process_sp->ReadMemory(process_address, bytes, size, error);
if (!error.Success())
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
break;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (lldb_private::Log *log =
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_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,
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
"IRMemoryMap::ReadMemory (0x%" PRIx64 ", 0x%" PRIxPTR
[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
", 0x%" PRId64 ") came from [0x%" PRIx64 "..0x%" PRIx64 ")",
[lldb] Fix ARM32 inferior calls echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
2019-12-21 18:12:17 +08:00
(uint64_t)process_address, reinterpret_cast<uintptr_t>(bytes), (uint64_t)size,
[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
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start +
(uint64_t)allocation.m_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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +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 IRMemoryMap::ReadScalarFromMemory(Scalar &scalar,
lldb::addr_t process_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
size_t size, Status &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (size > 0) {
DataBufferHeap buf(size, 0);
ReadMemory(buf.GetBytes(), process_address, size, error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (!error.Success())
return;
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
DataExtractor extractor(buf.GetBytes(), buf.GetByteSize(), GetByteOrder(),
GetAddressByteSize());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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::offset_t offset = 0;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
switch (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
default:
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
error.SetErrorToGenericError();
Fixed printf build warning. llvm-svn: 183250
2013-06-05 05:30:42 +08:00
error.SetErrorStringWithFormat(
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
"Couldn't read scalar: unsupported size %" PRIu64, (uint64_t)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;
case 1:
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
scalar = extractor.GetU8(&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
break;
case 2:
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
scalar = extractor.GetU16(&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
break;
case 4:
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
scalar = extractor.GetU32(&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
break;
case 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
scalar = extractor.GetU64(&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
break;
}
} else {
Hardened against reads in the IRMemoryMap that exceed the bounds of the backing memory. <rdar://problem/16088322> llvm-svn: 202899
2014-03-05 05:56:11 +08:00
error.SetErrorToGenericError();
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
error.SetErrorString("Couldn't read scalar: its size was zero");
*** 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
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
}
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 IRMemoryMap::ReadPointerFromMemory(lldb::addr_t *address,
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::addr_t process_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 &error) {
Updated the IRInterpreter to work with an IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
2013-04-17 15:50:58 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
Scalar pointer_scalar;
ReadScalarFromMemory(pointer_scalar, process_address, GetAddressByteSize(),
error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
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
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
*address = pointer_scalar.ULongLong();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
void IRMemoryMap::GetMemoryData(DataExtractor &extractor,
lldb::addr_t process_address, size_t size,
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 &error) {
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
error.Clear();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 (size > 0) {
AllocationMap::iterator iter = FindAllocation(process_address, 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
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (iter == m_allocations.end()) {
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
error.SetErrorToGenericError();
error.SetErrorStringWithFormat(
"Couldn't find an allocation containing [0x%" PRIx64 "..0x%" PRIx64
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
")",
process_address, process_address + size);
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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Allocation &allocation = iter->second;
*** 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
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
switch (allocation.m_policy) {
*** 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
default:
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
error.SetErrorToGenericError();
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorString(
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
"Couldn't get memory data: invalid allocation policy");
*** 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;
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
case eAllocationPolicyProcessOnly:
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
error.SetErrorToGenericError();
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error.SetErrorString(
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
"Couldn't get memory data: memory is only in the 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;
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
case eAllocationPolicyMirror: {
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
lldb::ProcessSP process_sp = m_process_wp.lock();
*** 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
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
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
error.SetErrorToGenericError();
error.SetErrorString("Couldn't get memory data: data buffer is empty");
return;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (process_sp) {
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
process_sp->ReadMemory(allocation.m_process_start,
allocation.m_data.GetBytes(),
allocation.m_data.GetByteSize(), error);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
*** 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;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
uint64_t offset = process_address - allocation.m_process_start;
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
extractor = DataExtractor(allocation.m_data.GetBytes() + offset, size,
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
GetByteOrder(), 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
return;
}
} break;
Fixed a few bugs in IRMemoryMap: - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
2013-04-16 05:35:52 +08:00
case eAllocationPolicyHostOnly:
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
if (!allocation.m_data.GetByteSize()) {
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
error.SetErrorToGenericError();
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
error.SetErrorString("Couldn't get memory data: data buffer is empty");
*** 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;
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
uint64_t offset = process_address - allocation.m_process_start;
Simplified the management of the data buffer for an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
2013-04-20 01:44:40 +08:00
extractor = DataExtractor(allocation.m_data.GetBytes() + offset, size,
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
GetByteOrder(), 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
return;
}
} else {
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
error.SetErrorToGenericError();
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
error.SetErrorString("Couldn't get memory data: its size was zero");
*** 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;
}
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
}