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

795 lines
24 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++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
#include "lldb/Core/DataBufferHeap.h"
#include "lldb/Core/DataExtractor.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/Core/Error.h"
#include "lldb/Core/Log.h"
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
#include "lldb/Core/Scalar.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/Expression/IRMemoryMap.h"
#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"
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)
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
{
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;
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
Error err;
while ((iter = m_allocations.begin()) != m_allocations.end())
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
{
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();
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->second.m_leak)
m_allocations.erase(iter);
else
Free(iter->first, err);
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)
{
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();
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
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
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 && 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
{
Error 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
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;
else
return ret;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
ret = 0;
if (!m_allocations.empty())
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
{
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
auto back = m_allocations.rbegin();
lldb::addr_t addr = back->first;
size_t alloc_size = back->second.m_size;
ret = llvm::RoundUpToAlignment(addr+alloc_size, 4096);
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
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)
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();
iter--;
}
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->first <= addr && iter->first + iter->second.m_size >= addr + size)
return iter;
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
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
bool
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
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;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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 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.
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;
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
if (iter != m_allocations.begin()) {
--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))
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 true;
}
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
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 that satisfy
// A<B and X<Y are the following:
// 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
// The first is B <= X, and the last is Y <= A.
// So the condition is !(B <= X || Y <= A)), or (X < B && A < Y)
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;
}
ExecutionContextScope *
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
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
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 NULL;
}
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),
m_size (size),
m_permissions (permissions),
m_alignment (alignment),
m_policy (policy),
m_leak (false)
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:
assert (0 && "We cannot reach this!");
case eAllocationPolicyHostOnly:
m_data.SetByteSize(size);
memset(m_data.GetBytes(), 0, size);
break;
case eAllocationPolicyProcessOnly:
break;
case eAllocationPolicyMirror:
m_data.SetByteSize(size);
memset(m_data.GetBytes(), 0, size);
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
lldb::addr_t
IRMemoryMap::Malloc (size_t size, uint8_t alignment, uint32_t permissions, AllocationPolicy policy, Error &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();
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::ProcessSP process_sp;
lldb::addr_t allocation_address = LLDB_INVALID_ADDRESS;
lldb::addr_t aligned_address = LLDB_INVALID_ADDRESS;
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 alignment_mask = alignment - 1;
size_t allocation_size;
if (size == 0)
allocation_size = alignment;
else
allocation_size = (size & alignment_mask) ? ((size + alignment) & (~alignment_mask)) : size;
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:
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;
}
break;
case eAllocationPolicyMirror:
process_sp = m_process_wp.lock();
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)
log->Printf ("IRMemoryMap::%s process_sp=0x%" PRIx64 ", process_sp->CanJIT()=%s, process_sp->IsAlive()=%s", __FUNCTION__, (lldb::addr_t) process_sp.get (), process_sp && process_sp->CanJIT () ? "true" : "false", process_sp && process_sp->IsAlive () ? "true" : "false");
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 && process_sp->CanJIT() && process_sp->IsAlive())
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 = process_sp->AllocateMemory(allocation_size, permissions, error);
if (!error.Success())
return LLDB_INVALID_ADDRESS;
}
else
{
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)
log->Printf ("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;
}
}
break;
case eAllocationPolicyProcessOnly:
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())
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
{
allocation_address = process_sp->AllocateMemory(allocation_size, permissions, error);
if (!error.Success())
return LLDB_INVALID_ADDRESS;
}
else
{
error.SetErrorToGenericError();
error.SetErrorString("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;
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
}
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
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't malloc: process doesn't exist, and this memory must be in the process");
return LLDB_INVALID_ADDRESS;
}
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);
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_allocations[aligned_address] = Allocation(allocation_address,
aligned_address,
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,
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
permissions,
alignment,
policy);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
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
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
log->Printf("IRMemoryMap::Malloc (%" PRIu64 ", 0x%" PRIx64 ", 0x%" PRIx64 ", %s) -> 0x%" PRIx64,
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
(uint64_t)allocation_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
(uint64_t)alignment,
(uint64_t)permissions,
policy_string,
aligned_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
return aligned_address;
}
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
void
IRMemoryMap::Leak (lldb::addr_t process_address, Error &error)
{
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;
}
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::Free (lldb::addr_t process_address, Error &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
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
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();
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)
{
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())
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
process_sp->DeallocateMemory(allocation.m_process_alloc); // FindSpace allocated this for real
}
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
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();
if (process_sp)
process_sp->DeallocateMemory(allocation.m_process_alloc);
}
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
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))
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
log->Printf("IRMemoryMap::Free (0x%" PRIx64 ") freed [0x%" PRIx64 "..0x%" PRIx64 ")",
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)process_address,
iter->second.m_process_start,
iter->second.m_process_start + iter->second.m_size);
}
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
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;
}
size = al.m_size;
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
void
IRMemoryMap::WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, size_t size, Error &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
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())
{
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();
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->WriteMemory(process_address, bytes, size, error);
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();
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 write: no allocation contains the target range and the process doesn't exist");
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
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;
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::ProcessSP process_sp;
switch (allocation.m_policy)
{
default:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write: invalid allocation policy");
return;
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");
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);
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;
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");
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);
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)
{
process_sp->WriteMemory(process_address, bytes, size, error);
if (!error.Success())
return;
}
break;
case eAllocationPolicyProcessOnly:
process_sp = m_process_wp.lock();
if (process_sp)
{
process_sp->WriteMemory(process_address, bytes, size, error);
if (!error.Success())
return;
}
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
if (lldb_private::Log *log = lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS))
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
log->Printf("IRMemoryMap::WriteMemory (0x%" PRIx64 ", 0x%" PRIx64 ", 0x%" PRId64 ") went to [0x%" PRIx64 "..0x%" PRIx64 ")",
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)process_address,
(uint64_t)bytes,
(uint64_t)size,
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start + (uint64_t)allocation.m_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
void
IRMemoryMap::WriteScalarToMemory (lldb::addr_t process_address, Scalar &scalar, size_t size, Error &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 == UINT32_MAX)
size = scalar.GetByteSize();
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)
{
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, lldb::addr_t address, Error &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, size_t size, Error &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
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())
{
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();
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;
}
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);
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();
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 read: no allocation contains the target range, and neither the process nor the target exist");
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
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;
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
if (offset > allocation.m_size)
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: data is not in the allocation");
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
lldb::ProcessSP process_sp;
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:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: invalid allocation policy");
return;
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");
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)
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't read: not enough underlying data");
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);
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;
case eAllocationPolicyMirror:
process_sp = m_process_wp.lock();
if (process_sp)
{
process_sp->ReadMemory(process_address, bytes, size, error);
if (!error.Success())
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");
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);
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;
case eAllocationPolicyProcessOnly:
process_sp = m_process_wp.lock();
if (process_sp)
{
process_sp->ReadMemory(process_address, bytes, size, error);
if (!error.Success())
return;
}
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
if (lldb_private::Log *log = lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS))
{
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
log->Printf("IRMemoryMap::ReadMemory (0x%" PRIx64 ", 0x%" PRIx64 ", 0x%" PRId64 ") came from [0x%" PRIx64 "..0x%" PRIx64 ")",
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)process_address,
(uint64_t)bytes,
(uint64_t)size,
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start + (uint64_t)allocation.m_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
void
IRMemoryMap::ReadScalarFromMemory (Scalar &scalar, lldb::addr_t process_address, size_t size, Error &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;
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
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
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::offset_t offset = 0;
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
switch (size)
{
default:
error.SetErrorToGenericError();
Fixed printf build warning. llvm-svn: 183250
2013-06-05 05:30:42 +08:00
error.SetErrorStringWithFormat("Couldn't read scalar: unsupported size %" PRIu64, (uint64_t)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
return;
case 1: scalar = extractor.GetU8(&offset); break;
case 2: scalar = extractor.GetU16(&offset); break;
case 4: scalar = extractor.GetU32(&offset); break;
case 8: scalar = extractor.GetU64(&offset); break;
}
}
else
{
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 read scalar: its size was zero");
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
}
return;
}
Added 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, lldb::addr_t process_address, Error &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
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!error.Success())
return;
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
*address = pointer_scalar.ULongLong();
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
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
void
IRMemoryMap::GetMemoryData (DataExtractor &extractor, lldb::addr_t process_address, size_t size, Error &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
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);
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 (iter == m_allocations.end())
{
error.SetErrorToGenericError();
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
error.SetErrorStringWithFormat("Couldn't find an allocation containing [0x%" PRIx64 "..0x%" PRIx64 ")", process_address, process_address + size);
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;
}
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
Allocation &allocation = iter->second;
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
switch (allocation.m_policy)
{
default:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't get memory data: invalid allocation policy");
return;
case eAllocationPolicyProcessOnly:
error.SetErrorToGenericError();
error.SetErrorString("Couldn't get memory data: memory is only in the target");
return;
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();
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())
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.SetErrorString("Couldn't get memory data: data buffer is empty");
return;
}
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);
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 (!error.Success())
return;
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, GetByteOrder(), GetAddressByteSize());
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
return;
}
}
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())
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;
}
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, GetByteOrder(), GetAddressByteSize());
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;
}
}
else
{
error.SetErrorToGenericError();
error.SetErrorString ("Couldn't get memory data: its size was zero");
return;
}
}