replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/source/Expression/Materializer.cpp

1412 lines
51 KiB
C++
Raw Normal View History

Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
//===-- Materializer.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/Log.h"
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
#include "lldb/Core/RegisterValue.h"
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
#include "lldb/Core/ValueObjectConstResult.h"
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
#include "lldb/Core/ValueObjectVariable.h"
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
#include "lldb/Expression/ClangExpressionVariable.h"
#include "lldb/Expression/Materializer.h"
#include "lldb/Symbol/ClangASTContext.h"
#include "lldb/Symbol/Symbol.h"
#include "lldb/Symbol/Type.h"
#include "lldb/Symbol/Variable.h"
#include "lldb/Target/ExecutionContext.h"
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
#include "lldb/Target/RegisterContext.h"
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
#include "lldb/Target/StackFrame.h"
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
#include "lldb/Target/Target.h"
Fixed a problem with materialization and dematerialization of registers that caused conditional breakpoint expressions not to work properly. Also added a testcase. <rdar://problem/14129252> llvm-svn: 184451
2013-06-21 02:42:16 +08:00
#include "lldb/Target/Thread.h"
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
using namespace lldb_private;
uint32_t
Materializer::AddStructMember (Entity &entity)
{
uint32_t size = entity.GetSize();
uint32_t alignment = entity.GetAlignment();
uint32_t ret;
Hand over the job of laying out the argument structure to the Materializer. Materialization is still done by the ClangExpressionDeclMap; this will be the next thing to move. Also fixed a layout bug that this uncovered. llvm-svn: 179318
2013-04-12 05:16:36 +08:00
if (m_current_offset == 0)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
m_struct_alignment = alignment;
if (m_current_offset % alignment)
m_current_offset += (alignment - (m_current_offset % alignment));
ret = m_current_offset;
m_current_offset += size;
return ret;
}
void
Materializer::Entity::SetSizeAndAlignmentFromType (ClangASTType &type)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_size = type.GetByteSize();
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t bit_alignment = type.GetTypeBitAlign();
if (bit_alignment % 8)
{
bit_alignment += 8;
bit_alignment &= ~((uint32_t)0x111u);
}
m_alignment = bit_alignment / 8;
}
class EntityPersistentVariable : public Materializer::Entity
{
public:
EntityPersistentVariable (lldb::ClangExpressionVariableSP &persistent_variable_sp) :
Entity(),
m_persistent_variable_sp(persistent_variable_sp)
{
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
// Hard-coding to maximum size of a pointer since persistent variables are materialized by reference
m_size = 8;
m_alignment = 8;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
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 MakeAllocation (IRMemoryMap &map, Error &err)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
// Allocate a spare memory area to store the persistent variable's contents.
Error allocate_error;
lldb::addr_t mem = map.Malloc(m_persistent_variable_sp->GetByteSize(),
8,
lldb::ePermissionsReadable | lldb::ePermissionsWritable,
IRMemoryMap::eAllocationPolicyMirror,
allocate_error);
if (!allocate_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't allocate a memory area to store %s: %s", m_persistent_variable_sp->GetName().GetCString(), allocate_error.AsCString());
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;
}
if (log)
log->Printf("Allocated %s (0x%" PRIx64 ") sucessfully", m_persistent_variable_sp->GetName().GetCString(), mem);
// Put the location of the spare memory into the live data of the ValueObject.
m_persistent_variable_sp->m_live_sp = ValueObjectConstResult::Create (map.GetBestExecutionContextScope(),
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_persistent_variable_sp->GetTypeFromUser(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->GetName(),
mem,
eAddressTypeLoad,
m_persistent_variable_sp->GetByteSize());
// Clear the flag if the variable will never be deallocated.
if (m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVKeepInTarget)
Fixed a bug where persistent variables did not live as long as they needed to. This led to equality tests involving persistent variables often failing or succeeding when they had no business doing so. To do this, I introduced the ability for a memory allocation to "leak" - that is, to persist in the process beyond the lifetime of the expression. Hand-declared persistent variables do this now. <rdar://problem/13956311> llvm-svn: 182528
2013-05-23 06:49:06 +08:00
{
Error leak_error;
map.Leak(mem, leak_error);
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_flags &= ~ClangExpressionVariable::EVNeedsAllocation;
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
}
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
// Write the contents of the variable to the area.
Error write_error;
map.WriteMemory (mem,
m_persistent_variable_sp->GetValueBytes(),
m_persistent_variable_sp->GetByteSize(),
write_error);
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat ("couldn't write %s to the target: %s", m_persistent_variable_sp->GetName().AsCString(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
write_error.AsCString());
return;
}
}
void DestroyAllocation (IRMemoryMap &map, Error &err)
{
Error deallocate_error;
map.Free((lldb::addr_t)m_persistent_variable_sp->m_live_sp->GetValue().GetScalar().ULongLong(), deallocate_error);
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
m_persistent_variable_sp->m_live_sp.reset();
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!deallocate_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat ("couldn't deallocate memory for %s: %s", m_persistent_variable_sp->GetName().GetCString(), deallocate_error.AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
}
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityPersistentVariable::Materialize [address = 0x%" PRIx64 ", m_name = %s, m_flags = 0x%hx]",
(uint64_t)load_addr,
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->GetName().AsCString(),
m_persistent_variable_sp->m_flags);
}
if (m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVNeedsAllocation)
{
MakeAllocation(map, err);
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
m_persistent_variable_sp->m_flags |= ClangExpressionVariable::EVIsLLDBAllocated;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!err.Success())
return;
}
if ((m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVIsProgramReference && m_persistent_variable_sp->m_live_sp) ||
m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVIsLLDBAllocated)
{
Error write_error;
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WriteScalarToMemory(load_addr,
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_live_sp->GetValue().GetScalar(),
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
map.GetAddressByteSize(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
write_error);
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the location of %s to memory: %s", m_persistent_variable_sp->GetName().AsCString(), write_error.AsCString());
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
}
}
else
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("no materialization happened for persistent variable %s", m_persistent_variable_sp->GetName().AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize (lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityPersistentVariable::Dematerialize [address = 0x%" PRIx64 ", m_name = %s, m_flags = 0x%hx]",
(uint64_t)process_address + m_offset,
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->GetName().AsCString(),
m_persistent_variable_sp->m_flags);
}
if ((m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVIsLLDBAllocated) ||
(m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVIsProgramReference))
{
if (m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVIsProgramReference &&
!m_persistent_variable_sp->m_live_sp)
{
// If the reference comes from the program, then the ClangExpressionVariable's
// live variable data hasn't been set up yet. Do this now.
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
lldb::addr_t location;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
Error read_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadPointerFromMemory(&location, load_addr, read_error);
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
if (!read_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't read the address of program-allocated variable %s: %s", m_persistent_variable_sp->GetName().GetCString(), read_error.AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
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
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->m_live_sp = ValueObjectConstResult::Create (map.GetBestExecutionContextScope (),
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_persistent_variable_sp->GetTypeFromUser(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_persistent_variable_sp->GetName(),
location,
eAddressTypeLoad,
m_persistent_variable_sp->GetByteSize());
if (frame_top != LLDB_INVALID_ADDRESS &&
frame_bottom != LLDB_INVALID_ADDRESS &&
location >= frame_bottom &&
location <= frame_top)
{
// If the variable is resident in the stack frame created by the expression,
// then it cannot be relied upon to stay around. We treat it as needing
// reallocation.
m_persistent_variable_sp->m_flags |= ClangExpressionVariable::EVIsLLDBAllocated;
m_persistent_variable_sp->m_flags |= ClangExpressionVariable::EVNeedsAllocation;
m_persistent_variable_sp->m_flags |= ClangExpressionVariable::EVNeedsFreezeDry;
m_persistent_variable_sp->m_flags &= ~ClangExpressionVariable::EVIsProgramReference;
}
}
lldb::addr_t mem = m_persistent_variable_sp->m_live_sp->GetValue().GetScalar().ULongLong();
if (!m_persistent_variable_sp->m_live_sp)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't find the memory area used to store %s", m_persistent_variable_sp->GetName().GetCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
if (m_persistent_variable_sp->m_live_sp->GetValue().GetValueAddressType() != eAddressTypeLoad)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("the address of the memory area for %s is in an incorrect format", m_persistent_variable_sp->GetName().GetCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
if (m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVNeedsFreezeDry ||
m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVKeepInTarget)
{
if (log)
log->Printf("Dematerializing %s from 0x%" PRIx64 " (size = %llu)", m_persistent_variable_sp->GetName().GetCString(), (uint64_t)mem, (unsigned long long)m_persistent_variable_sp->GetByteSize());
// Read the contents of the spare memory area
m_persistent_variable_sp->ValueUpdated ();
Error read_error;
map.ReadMemory(m_persistent_variable_sp->GetValueBytes(),
mem,
m_persistent_variable_sp->GetByteSize(),
read_error);
if (!read_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat ("couldn't read the contents of %s from memory: %s", m_persistent_variable_sp->GetName().GetCString(), read_error.AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
m_persistent_variable_sp->m_flags &= ~ClangExpressionVariable::EVNeedsFreezeDry;
}
}
else
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("no dematerialization happened for persistent variable %s", m_persistent_variable_sp->GetName().AsCString());
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
return;
}
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
lldb::ProcessSP process_sp = map.GetBestExecutionContextScope()->CalculateProcess();
if (!process_sp ||
!process_sp->CanJIT())
{
// Allocations are not persistent so persistent variables cannot stay materialized.
m_persistent_variable_sp->m_flags |= ClangExpressionVariable::EVNeedsAllocation;
DestroyAllocation(map, err);
if (!err.Success())
return;
}
else if (m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVNeedsAllocation &&
!(m_persistent_variable_sp->m_flags & ClangExpressionVariable::EVKeepInTarget))
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
{
DestroyAllocation(map, err);
if (!err.Success())
return;
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog (IRMemoryMap &map, lldb::addr_t process_address, Log *log)
{
StreamString dump_stream;
Error err;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityPersistentVariable (%s)\n", load_addr, m_persistent_variable_sp->GetName().AsCString());
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Pointer:\n");
DataBufferHeap data (m_size, 0);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
{
dump_stream.Printf("Target:\n");
lldb::addr_t target_address;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadPointerFromMemory (&target_address, load_addr, err);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataBufferHeap data (m_persistent_variable_sp->GetByteSize(), 0);
map.ReadMemory(data.GetBytes(), target_address, m_persistent_variable_sp->GetByteSize(), err);
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, target_address);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
}
log->PutCString(dump_stream.GetData());
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe (IRMemoryMap &map, lldb::addr_t process_address)
{
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
lldb::ClangExpressionVariableSP m_persistent_variable_sp;
};
uint32_t
Materializer::AddPersistentVariable (lldb::ClangExpressionVariableSP &persistent_variable_sp, Error &err)
{
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
iter->reset (new EntityPersistentVariable (persistent_variable_sp));
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityVariable : public Materializer::Entity
{
public:
EntityVariable (lldb::VariableSP &variable_sp) :
Entity(),
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
m_variable_sp(variable_sp),
m_is_reference(false),
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
m_temporary_allocation(LLDB_INVALID_ADDRESS),
m_temporary_allocation_size(0)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
// Hard-coding to maximum size of a pointer since all variables are materialized by reference
Hand over the job of laying out the argument structure to the Materializer. Materialization is still done by the ClangExpressionDeclMap; this will be the next thing to move. Also fixed a layout bug that this uncovered. llvm-svn: 179318
2013-04-12 05:16:36 +08:00
m_size = 8;
m_alignment = 8;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_is_reference = m_variable_sp->GetType()->GetClangForwardType().IsReferenceType();
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityVariable::Materialize [address = 0x%" PRIx64 ", m_variable_sp = %s]",
(uint64_t)load_addr,
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
m_variable_sp->GetName().AsCString());
}
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
ExecutionContextScope *scope = frame_sp.get();
if (!scope)
scope = map.GetBestExecutionContextScope();
lldb::ValueObjectSP valobj_sp = ValueObjectVariable::Create(scope, m_variable_sp);
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!valobj_sp)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get a value object for variable %s", m_variable_sp->GetName().AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
if (m_is_reference)
{
DataExtractor valobj_extractor;
valobj_sp->GetData(valobj_extractor);
lldb::offset_t offset = 0;
lldb::addr_t reference_addr = valobj_extractor.GetAddress(&offset);
Error write_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, reference_addr, write_error);
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the contents of reference variable %s to memory: %s", m_variable_sp->GetName().AsCString(), write_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
}
else
{
Simplified the code that materializes a variable, obviating the need to create a new ValueObject. llvm-svn: 193191
2013-10-23 04:01:17 +08:00
lldb::addr_t addr_of_valobj = valobj_sp->GetAddressOf();
if (addr_of_valobj != LLDB_INVALID_ADDRESS)
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
{
Error write_error;
Simplified the code that materializes a variable, obviating the need to create a new ValueObject. llvm-svn: 193191
2013-10-23 04:01:17 +08:00
map.WritePointerToMemory(load_addr, addr_of_valobj, write_error);
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the address of variable %s to memory: %s", m_variable_sp->GetName().AsCString(), write_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
}
else
{
DataExtractor data;
valobj_sp->GetData(data);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (m_temporary_allocation != LLDB_INVALID_ADDRESS)
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
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("trying to create a temporary region for %s but one exists", m_variable_sp->GetName().AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
if (data.GetByteSize() != m_variable_sp->GetType()->GetByteSize())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
if (data.GetByteSize() == 0 && m_variable_sp->LocationExpression().IsValid() == false)
{
err.SetErrorStringWithFormat("the variable '%s' has no location, it may have been optimized out", m_variable_sp->GetName().AsCString());
}
else
{
Fixed printf warnings. The GetByteSize() results return uint64_t values, not size_t values. llvm-svn: 194587
2013-11-14 02:01:16 +08:00
err.SetErrorStringWithFormat("size of variable %s (%" PRIu64 ") disagrees with the ValueObject's size (%" PRIu64 ")",
m_variable_sp->GetName().AsCString(),
m_variable_sp->GetType()->GetByteSize(),
data.GetByteSize());
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
}
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
size_t bit_align = m_variable_sp->GetType()->GetClangLayoutType().GetTypeBitAlign();
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
size_t byte_align = (bit_align + 7) / 8;
Error alloc_error;
m_temporary_allocation = map.Malloc(data.GetByteSize(), byte_align, lldb::ePermissionsReadable | lldb::ePermissionsWritable, IRMemoryMap::eAllocationPolicyMirror, alloc_error);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
m_temporary_allocation_size = data.GetByteSize();
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!alloc_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't allocate a temporary region for %s: %s", m_variable_sp->GetName().AsCString(), alloc_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Error write_error;
map.WriteMemory(m_temporary_allocation, data.GetDataStart(), data.GetByteSize(), write_error);
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write to the temporary region for %s: %s", m_variable_sp->GetName().AsCString(), write_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Error pointer_write_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, m_temporary_allocation, pointer_write_error);
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!pointer_write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the address of the temporary region for %s: %s", m_variable_sp->GetName().AsCString(), pointer_write_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
}
}
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize (lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityVariable::Dematerialize [address = 0x%" PRIx64 ", m_variable_sp = %s]",
(uint64_t)load_addr,
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
m_variable_sp->GetName().AsCString());
}
if (m_temporary_allocation != LLDB_INVALID_ADDRESS)
{
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
ExecutionContextScope *scope = frame_sp.get();
if (!scope)
scope = map.GetBestExecutionContextScope();
lldb::ValueObjectSP valobj_sp = ValueObjectVariable::Create(scope, m_variable_sp);
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
if (!valobj_sp)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get a value object for variable %s", m_variable_sp->GetName().AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
lldb_private::DataExtractor data;
Error extract_error;
map.GetMemoryData(data, m_temporary_allocation, valobj_sp->GetByteSize(), extract_error);
if (!extract_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for variable %s", m_variable_sp->GetName().AsCString());
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
return;
}
Error set_error;
valobj_sp->SetData(data, set_error);
if (!set_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the new contents of %s back into the variable", m_variable_sp->GetName().AsCString());
Now that ValueObjects permit writing, made the Materializer use that API when dematerializing variables. llvm-svn: 179443
2013-04-13 10:06:42 +08:00
return;
}
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
Error free_error;
map.Free(m_temporary_allocation, free_error);
if (!free_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't free the temporary region for %s: %s", m_variable_sp->GetName().AsCString(), free_error.AsCString());
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
return;
}
m_temporary_allocation = LLDB_INVALID_ADDRESS;
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
m_temporary_allocation_size = 0;
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
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog (IRMemoryMap &map, lldb::addr_t process_address, Log *log)
{
StreamString dump_stream;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityVariable\n", load_addr);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
This commit 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
Error err;
lldb::addr_t ptr = LLDB_INVALID_ADDRESS;
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Pointer:\n");
DataBufferHeap data (m_size, 0);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
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
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::offset_t offset;
ptr = extractor.GetPointer(&offset);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
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 (m_temporary_allocation == LLDB_INVALID_ADDRESS)
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
dump_stream.Printf("Points to process memory:\n");
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
else
{
dump_stream.Printf("Temporary allocation:\n");
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
}
if (ptr == LLDB_INVALID_ADDRESS)
{
dump_stream.Printf(" <could not be be found>\n");
}
else
{
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
DataBufferHeap data (m_temporary_allocation_size, 0);
map.ReadMemory(data.GetBytes(), m_temporary_allocation, m_temporary_allocation_size, err);
if (!err.Success())
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
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
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
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
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
log->PutCString(dump_stream.GetData());
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe (IRMemoryMap &map, lldb::addr_t process_address)
{
if (m_temporary_allocation != LLDB_INVALID_ADDRESS)
{
Error free_error;
map.Free(m_temporary_allocation, free_error);
m_temporary_allocation = LLDB_INVALID_ADDRESS;
m_temporary_allocation_size = 0;
}
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
Implemented materialization and dematerialization for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
2013-04-13 05:40:34 +08:00
lldb::VariableSP m_variable_sp;
bool m_is_reference;
lldb::addr_t m_temporary_allocation;
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
size_t m_temporary_allocation_size;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
uint32_t
Materializer::AddVariable (lldb::VariableSP &variable_sp, Error &err)
{
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
iter->reset (new EntityVariable (variable_sp));
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityResultVariable : public Materializer::Entity
{
public:
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
EntityResultVariable (const TypeFromUser &type, bool is_program_reference, bool keep_in_memory) :
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Entity(),
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
m_type(type),
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_is_program_reference(is_program_reference),
m_keep_in_memory(keep_in_memory),
m_temporary_allocation(LLDB_INVALID_ADDRESS),
m_temporary_allocation_size(0)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
// Hard-coding to maximum size of a pointer since all results are materialized by reference
m_size = 8;
m_alignment = 8;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!m_is_program_reference)
{
if (m_temporary_allocation != LLDB_INVALID_ADDRESS)
{
err.SetErrorString("Trying to create a temporary region for the result but one exists");
return;
}
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
size_t byte_size = m_type.GetByteSize();
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
size_t bit_align = m_type.GetTypeBitAlign();
size_t byte_align = (bit_align + 7) / 8;
Error alloc_error;
m_temporary_allocation = map.Malloc(byte_size, byte_align, lldb::ePermissionsReadable | lldb::ePermissionsWritable, IRMemoryMap::eAllocationPolicyMirror, alloc_error);
m_temporary_allocation_size = byte_size;
if (!alloc_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't allocate a temporary region for the result: %s", alloc_error.AsCString());
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
return;
}
Error pointer_write_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, m_temporary_allocation, pointer_write_error);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!pointer_write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the address of the temporary region for the result: %s", pointer_write_error.AsCString());
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
}
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize (lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
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
err.SetErrorString("Tried to detmaterialize a result variable with the normal Dematerialize method");
}
void Dematerialize (lldb::ClangExpressionVariableSP &result_variable_sp,
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
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
{
err.Clear();
ExecutionContextScope *exe_scope = map.GetBestExecutionContextScope();
if (!exe_scope)
{
err.SetErrorString("Couldn't dematerialize a result variable: invalid execution context scope");
return;
}
lldb::addr_t address;
Error read_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
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
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadPointerFromMemory (&address, load_addr, read_error);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!read_error.Success())
{
err.SetErrorString("Couldn't dematerialize a result variable: couldn't read its address");
return;
}
lldb::TargetSP target_sp = exe_scope->CalculateTarget();
if (!target_sp)
{
err.SetErrorString("Couldn't dematerialize a result variable: no target");
return;
}
ConstString name = target_sp->GetPersistentVariables().GetNextPersistentVariableName();
lldb::ClangExpressionVariableSP ret;
ret = target_sp->GetPersistentVariables().CreateVariable(exe_scope,
name,
m_type,
map.GetByteOrder(),
map.GetAddressByteSize());
if (!ret)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't dematerialize a result variable: failed to make persistent variable %s", name.AsCString());
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
return;
}
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
lldb::ProcessSP process_sp = map.GetBestExecutionContextScope()->CalculateProcess();
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
bool can_persist = (m_is_program_reference && process_sp && process_sp->CanJIT() && !(address >= frame_bottom && address < frame_top));
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
if (can_persist && m_keep_in_memory)
{
ret->m_live_sp = ValueObjectConstResult::Create(exe_scope,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_type,
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
name,
address,
eAddressTypeLoad,
Fixed a bug in the Materializer where we sent the wrong information to ValueObjectConstResult. <rdar://problem/15101795> llvm-svn: 192264
2013-10-09 10:04:57 +08:00
map.GetAddressByteSize());
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
}
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
ret->ValueUpdated();
const size_t pvar_byte_size = ret->GetByteSize();
uint8_t *pvar_data = ret->GetValueBytes();
map.ReadMemory(pvar_data, address, pvar_byte_size, read_error);
if (!read_error.Success())
{
err.SetErrorString("Couldn't dematerialize a result variable: couldn't read its memory");
return;
}
result_variable_sp = ret;
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
if (!can_persist || !m_keep_in_memory)
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
{
ret->m_flags |= ClangExpressionVariable::EVNeedsAllocation;
Fixed the expression parser's handling of result and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
2013-04-20 10:40:45 +08:00
if (m_temporary_allocation != LLDB_INVALID_ADDRESS)
{
Error free_error;
map.Free(m_temporary_allocation, free_error);
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
}
else
{
ret->m_flags |= ClangExpressionVariable::EVIsLLDBAllocated;
}
m_temporary_allocation = LLDB_INVALID_ADDRESS;
m_temporary_allocation_size = 0;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog (IRMemoryMap &map, lldb::addr_t process_address, Log *log)
{
StreamString dump_stream;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityResultVariable\n", load_addr);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
This commit 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
Error err;
lldb::addr_t ptr = LLDB_INVALID_ADDRESS;
{
dump_stream.Printf("Pointer:\n");
DataBufferHeap data (m_size, 0);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::offset_t offset;
ptr = extractor.GetPointer(&offset);
dump_stream.PutChar('\n');
}
}
if (m_temporary_allocation == LLDB_INVALID_ADDRESS)
{
dump_stream.Printf("Points to process memory:\n");
}
else
{
dump_stream.Printf("Temporary allocation:\n");
}
if (ptr == LLDB_INVALID_ADDRESS)
{
dump_stream.Printf(" <could not be be found>\n");
}
else
{
DataBufferHeap data (m_temporary_allocation_size, 0);
map.ReadMemory(data.GetBytes(), m_temporary_allocation, m_temporary_allocation_size, err);
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
dump_stream.PutChar('\n');
}
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
log->PutCString(dump_stream.GetData());
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe (IRMemoryMap &map, lldb::addr_t process_address)
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!m_keep_in_memory && m_temporary_allocation != LLDB_INVALID_ADDRESS)
{
Error free_error;
map.Free(m_temporary_allocation, free_error);
}
m_temporary_allocation = LLDB_INVALID_ADDRESS;
m_temporary_allocation_size = 0;
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
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
This 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
TypeFromUser m_type;
bool m_is_program_reference;
Replicated the materialization logic for persistent variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
2013-04-13 02:10:34 +08:00
bool m_keep_in_memory;
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
lldb::addr_t m_temporary_allocation;
size_t m_temporary_allocation_size;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
uint32_t
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
Materializer::AddResultVariable (const TypeFromUser &type, bool is_program_reference, bool keep_in_memory, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
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
iter->reset (new EntityResultVariable (type, is_program_reference, keep_in_memory));
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_result_entity = iter->get();
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
return ret;
}
class EntitySymbol : public Materializer::Entity
{
public:
EntitySymbol (const Symbol &symbol) :
Entity(),
m_symbol(symbol)
{
// Hard-coding to maximum size of a symbol
m_size = 8;
m_alignment = 8;
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntitySymbol::Materialize [address = 0x%" PRIx64 ", m_symbol = %s]",
(uint64_t)load_addr,
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
m_symbol.GetName().AsCString());
}
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
Address &sym_address = m_symbol.GetAddress();
ExecutionContextScope *exe_scope = map.GetBestExecutionContextScope();
lldb::TargetSP target_sp;
if (exe_scope)
target_sp = map.GetBestExecutionContextScope()->CalculateTarget();
if (!target_sp)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't resolve symbol %s because there is no target", m_symbol.GetName().AsCString());
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
return;
}
lldb::addr_t resolved_address = sym_address.GetLoadAddress(target_sp.get());
if (resolved_address == LLDB_INVALID_ADDRESS)
resolved_address = sym_address.GetFileAddress();
Error pointer_write_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WritePointerToMemory(load_addr, resolved_address, pointer_write_error);
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
if (!pointer_write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the address of symbol %s: %s", m_symbol.GetName().AsCString(), pointer_write_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize (lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntitySymbol::Dematerialize [address = 0x%" PRIx64 ", m_symbol = %s]",
(uint64_t)load_addr,
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
m_symbol.GetName().AsCString());
}
Added symbol materialization support to the new Materializer. llvm-svn: 179445
2013-04-13 10:25:02 +08:00
// no work needs to be done
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog (IRMemoryMap &map, lldb::addr_t process_address, Log *log)
{
StreamString dump_stream;
Error err;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntitySymbol (%s)\n", load_addr, m_symbol.GetName().AsCString());
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Pointer:\n");
DataBufferHeap data (m_size, 0);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
log->PutCString(dump_stream.GetData());
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe (IRMemoryMap &map, lldb::addr_t process_address)
{
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
Symbol m_symbol;
};
uint32_t
Materializer::AddSymbol (const Symbol &symbol_sp, Error &err)
{
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
iter->reset (new EntitySymbol (symbol_sp));
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
class EntityRegister : public Materializer::Entity
{
public:
EntityRegister (const RegisterInfo &register_info) :
Entity(),
m_register_info(register_info)
{
// Hard-coding alignment conservatively
m_size = m_register_info.byte_size;
m_alignment = m_register_info.byte_size;
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityRegister::Materialize [address = 0x%" PRIx64 ", m_register_info = %s]",
(uint64_t)load_addr,
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
m_register_info.name);
}
RegisterValue reg_value;
if (!frame_sp.get())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't materialize register %s without a stack frame", m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
lldb::RegisterContextSP reg_context_sp = frame_sp->GetRegisterContext();
if (!reg_context_sp->ReadRegister(&m_register_info, reg_value))
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't read the value of register %s", m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
DataExtractor register_data;
if (!reg_value.GetData(register_data))
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for register %s", m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
if (register_data.GetByteSize() != m_register_info.byte_size)
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("data for register %s had size %llu but we expected %llu", m_register_info.name, (unsigned long long)register_data.GetByteSize(), (unsigned long long)m_register_info.byte_size);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
m_register_contents.reset(new DataBufferHeap(register_data.GetDataStart(), register_data.GetByteSize()));
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Error write_error;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.WriteMemory(load_addr, register_data.GetDataStart(), register_data.GetByteSize(), write_error);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!write_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the contents of register %s: %s", m_register_info.name, write_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
void Dematerialize (lldb::StackFrameSP &frame_sp,
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
IRMemoryMap &map,
lldb::addr_t process_address,
lldb::addr_t frame_top,
lldb::addr_t frame_bottom,
Error &err)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (log)
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
log->Printf("EntityRegister::Dematerialize [address = 0x%" PRIx64 ", m_register_info = %s]",
(uint64_t)load_addr,
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
m_register_info.name);
}
Error extract_error;
DataExtractor register_data;
if (!frame_sp.get())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't dematerialize register %s without a stack frame", m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
lldb::RegisterContextSP reg_context_sp = frame_sp->GetRegisterContext();
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.GetMemoryData(register_data, load_addr, m_register_info.byte_size, extract_error);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
if (!extract_error.Success())
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't get the data for register %s: %s", m_register_info.name, extract_error.AsCString());
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
if (!memcmp(register_data.GetDataStart(), m_register_contents->GetBytes(), register_data.GetByteSize()))
{
// No write required, and in particular we avoid errors if the register wasn't writable
m_register_contents.reset();
return;
}
m_register_contents.reset();
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
RegisterValue register_value (const_cast<uint8_t*>(register_data.GetDataStart()), register_data.GetByteSize(), register_data.GetByteOrder());
if (!reg_context_sp->WriteRegister(&m_register_info, register_value))
{
<rdar://problem/13893094> Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
2013-05-17 08:55:28 +08:00
err.SetErrorStringWithFormat("couldn't write the value of register %s", m_register_info.name);
Added support for registers to the Materializer. Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
2013-04-16 04:51:24 +08:00
return;
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
void DumpToLog (IRMemoryMap &map, lldb::addr_t process_address, Log *log)
{
StreamString dump_stream;
Error err;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
const lldb::addr_t load_addr = process_address + m_offset;
dump_stream.Printf("0x%" PRIx64 ": EntityRegister (%s)\n", load_addr, m_register_info.name);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
{
dump_stream.Printf("Value:\n");
DataBufferHeap data (m_size, 0);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
map.ReadMemory(data.GetBytes(), load_addr, m_size, err);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
if (!err.Success())
{
dump_stream.Printf(" <could not be read>\n");
}
else
{
DataExtractor extractor (data.GetBytes(), data.GetByteSize(), map.GetByteOrder(), map.GetAddressByteSize());
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
extractor.DumpHexBytes(&dump_stream, data.GetBytes(), data.GetByteSize(), 16, load_addr);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
dump_stream.PutChar('\n');
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
}
}
log->PutCString(dump_stream.GetData());
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
void Wipe (IRMemoryMap &map, lldb::addr_t process_address)
{
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
private:
RegisterInfo m_register_info;
Modified the expression parser to only try to write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
2013-07-13 07:35:21 +08:00
lldb::DataBufferSP m_register_contents;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
};
uint32_t
Materializer::AddRegister (const RegisterInfo &register_info, Error &err)
{
EntityVector::iterator iter = m_entities.insert(m_entities.end(), EntityUP());
iter->reset (new EntityRegister (register_info));
uint32_t ret = AddStructMember(**iter);
(*iter)->SetOffset(ret);
return ret;
}
Materializer::Materializer () :
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_dematerializer_wp(),
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_result_entity(NULL),
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
m_current_offset(0),
m_struct_alignment(8)
{
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Materializer::~Materializer ()
{
DematerializerSP dematerializer_sp = m_dematerializer_wp.lock();
if (dematerializer_sp)
dematerializer_sp->Wipe();
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Materializer::DematerializerSP
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
Materializer::Materialize (lldb::StackFrameSP &frame_sp, IRMemoryMap &map, lldb::addr_t process_address, Error &error)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
ExecutionContextScope *exe_scope = frame_sp.get();
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
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!exe_scope)
exe_scope = map.GetBestExecutionContextScope();
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
DematerializerSP dematerializer_sp = m_dematerializer_wp.lock();
if (dematerializer_sp)
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't materialize: already materialized");
}
DematerializerSP ret(new Dematerializer(*this, frame_sp, map, process_address));
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!exe_scope)
{
error.SetErrorToGenericError();
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
error.SetErrorString("Couldn't materialize: target doesn't exist");
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
for (EntityUP &entity_up : m_entities)
{
entity_up->Materialize(frame_sp, map, process_address, error);
if (!error.Success())
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
return DematerializerSP();
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
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 (Log *log = lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS))
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
{
Fix various build warnings. llvm-svn: 183140
2013-06-04 02:00:07 +08:00
log->Printf("Materializer::Materialize (frame_sp = %p, process_address = 0x%" PRIx64 ") materialized:", frame_sp.get(), process_address);
Added logging to each entity in the Materializer to make debugging easier when things go wrong. llvm-svn: 179576
2013-04-16 06:48:23 +08:00
for (EntityUP &entity_up : m_entities)
entity_up->DumpToLog(map, process_address, log);
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_dematerializer_wp = ret;
return ret;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
void
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
Materializer::Dematerializer::Dematerialize (Error &error, lldb::ClangExpressionVariableSP &result_sp, lldb::addr_t frame_bottom, lldb::addr_t frame_top)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
lldb::StackFrameSP frame_sp;
Fixed a problem with materialization and dematerialization of registers that caused conditional breakpoint expressions not to work properly. Also added a testcase. <rdar://problem/14129252> llvm-svn: 184451
2013-06-21 02:42:16 +08:00
lldb::ThreadSP thread_sp = m_thread_wp.lock();
if (thread_sp)
frame_sp = thread_sp->GetFrameWithStackID(m_stack_id);
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
ExecutionContextScope *exe_scope = m_map->GetBestExecutionContextScope();
if (!IsValid())
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't dematerialize: invalid dematerializer");
}
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
if (!exe_scope)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
error.SetErrorToGenericError();
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
error.SetErrorString("Couldn't dematerialize: target is gone");
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}
else
{
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 (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("Materializer::Dematerialize (frame_sp = %p, process_address = 0x%" PRIx64 ") about to dematerialize:", frame_sp.get(), m_process_address);
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
for (EntityUP &entity_up : m_materializer->m_entities)
entity_up->DumpToLog(*m_map, m_process_address, log);
Added 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
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
for (EntityUP &entity_up : m_materializer->m_entities)
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
{
This commit 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 (entity_up.get() == m_materializer->m_result_entity)
{
static_cast<EntityResultVariable*>(m_materializer->m_result_entity)->Dematerialize (result_sp, frame_sp, *m_map, m_process_address, frame_top, frame_bottom, error);
}
else
{
entity_up->Dematerialize (frame_sp, *m_map, m_process_address, frame_top, frame_bottom, error);
}
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
if (!error.Success())
break;
}
}
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
Wipe();
}
void
Materializer::Dematerializer::Wipe ()
{
if (!IsValid())
return;
for (EntityUP &entity_up : m_materializer->m_entities)
{
entity_up->Wipe (*m_map, m_process_address);
}
m_materializer = NULL;
m_map = NULL;
m_process_address = LLDB_INVALID_ADDRESS;
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 08:09:05 +08:00
}