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

2820 lines
90 KiB
C++
Raw Normal View History

This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
//===-- IRForTarget.cpp -----------------------------------------*- C++ -*-===//
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Expression/IRForTarget.h"
#include "llvm/Support/raw_ostream.h"
Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to reflect the migration in r171366. I don't know anything about lldb, but a force run of the build bot indicated it would need this patch. I'll try to watch the build bot to get it green. llvm-svn: 171374
2013-01-02 20:20:07 +08:00
#include "llvm/IR/Constants.h"
#include "llvm/IR/DataLayout.h"
#include "llvm/IR/InstrTypes.h"
#include "llvm/IR/Instructions.h"
#include "llvm/IR/Intrinsics.h"
#include "llvm/IR/Module.h"
Fix build after r229094: replace llvm/PassManager.h -> llvm/IR/LegacyPassManager.h llvm-svn: 229100
2015-02-13 18:49:18 +08:00
#include "llvm/IR/LegacyPassManager.h"
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
#include "llvm/Transforms/IPO.h"
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
#include "llvm/IR/Metadata.h"
Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to reflect the migration in r171366. I don't know anything about lldb, but a force run of the build bot indicated it would need this patch. I'll try to watch the build bot to get it green. llvm-svn: 171374
2013-01-02 20:20:07 +08:00
#include "llvm/IR/ValueSymbolTable.h"
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
#include "clang/AST/ASTContext.h"
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
#include "lldb/Core/dwarf.h"
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
#include "lldb/Core/ConstString.h"
#include "lldb/Core/DataBufferHeap.h"
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
#include "lldb/Core/Log.h"
#include "lldb/Core/Scalar.h"
#include "lldb/Core/StreamString.h"
#include "lldb/Expression/ClangExpressionDeclMap.h"
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
#include "lldb/Expression/IRExecutionUnit.h"
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
#include "lldb/Expression/IRInterpreter.h"
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
#include "lldb/Host/Endian.h"
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
#include "lldb/Symbol/ClangASTContext.h"
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
#include "lldb/Symbol/ClangASTType.h"
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
#include "lldb/Target/CPPLanguageRuntime.h"
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
#include <map>
using namespace llvm;
Patch by Bill Lynch fixing handling of the pid in the IR transformation passes. llvm-svn: 111388
2010-08-19 02:50:51 +08:00
static char ID;
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
IRForTarget::StaticDataAllocator::StaticDataAllocator(lldb_private::IRExecutionUnit &execution_unit) :
m_execution_unit(execution_unit),
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_stream_string(lldb_private::Stream::eBinary, execution_unit.GetAddressByteSize(), execution_unit.GetByteOrder()),
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_allocation(LLDB_INVALID_ADDRESS)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
}
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
IRForTarget::FunctionValueCache::FunctionValueCache(Maker const &maker) :
m_maker(maker),
m_values()
{
}
IRForTarget::FunctionValueCache::~FunctionValueCache()
{
}
Make a more complete fix for always supplying an execution context when getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-02-12 08:34:25 +08:00
llvm::Value *
IRForTarget::FunctionValueCache::GetValue(llvm::Function *function)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!m_values.count(function))
{
llvm::Value *ret = m_maker(function);
m_values[function] = ret;
return ret;
}
return m_values[function];
}
Make a more complete fix for always supplying an execution context when getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-02-12 08:34:25 +08:00
lldb::addr_t
IRForTarget::StaticDataAllocator::Allocate()
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
lldb_private::Error err;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
if (m_allocation != LLDB_INVALID_ADDRESS)
{
m_execution_unit.FreeNow(m_allocation);
m_allocation = LLDB_INVALID_ADDRESS;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_allocation = m_execution_unit.WriteNow((const uint8_t*)m_stream_string.GetData(), m_stream_string.GetSize(), err);
return m_allocation;
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
Make a more complete fix for always supplying an execution context when getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-02-12 08:34:25 +08:00
lldb::TargetSP
IRForTarget::StaticDataAllocator::GetTarget()
{
return m_execution_unit.GetTarget();
}
static llvm::Value *
FindEntryInstruction (llvm::Function *function)
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
{
if (function->empty())
return NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return function->getEntryBlock().getFirstNonPHIOrDbg();
}
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
IRForTarget::IRForTarget (lldb_private::ClangExpressionDeclMap *decl_map,
bool resolve_vars,
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
lldb_private::IRExecutionUnit &execution_unit,
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
lldb_private::Stream *error_stream,
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
const char *func_name) :
Updated to latest LLVM. Major LLVM changes: - Sema is now exported (and there was much rejoicing.) - Storage classes are now centrally defined. Also fixed some bugs that the new LLVM picked up. llvm-svn: 114622
2010-09-23 11:01:22 +08:00
ModulePass(ID),
Order of initialization lists. This patch fixes all of the warnings due to unordered initialization lists. Patch by Marco Minutoli. llvm-svn: 129290
2011-04-12 03:41:40 +08:00
m_resolve_vars(resolve_vars),
m_func_name(func_name),
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_module(NULL),
Patch by Matt Johnson to silence G++ warnings! Used hand merge to apply the diffs. I did not apply the diffs for FormatManager.h and the diffs for memberwise initialization for ValueObject.cpp because they changed since. I will ask my colleague to apply them later. llvm-svn: 135508
2011-07-20 03:48:13 +08:00
m_decl_map(decl_map),
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator(execution_unit),
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
m_CFStringCreateWithBytes(NULL),
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_sel_registerName(NULL),
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
m_intptr_ty(NULL),
Order of initialization lists. This patch fixes all of the warnings due to unordered initialization lists. Patch by Marco Minutoli. llvm-svn: 129290
2011-04-12 03:41:40 +08:00
m_error_stream(error_stream),
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
m_result_store(NULL),
m_result_is_pointer(false),
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
m_reloc_placeholder(NULL),
m_entry_instruction_finder (FindEntryInstruction)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
}
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
/* Handy utility functions used at several places in the code */
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
static std::string
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
PrintValue(const Value *value, bool truncate = false)
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
{
std::string s;
Bunch of cleanups for warnings found by the llvm static analyzer. llvm-svn: 165808
2012-10-13 01:34:26 +08:00
if (value)
{
raw_string_ostream rso(s);
value->print(rso);
rso.flush();
if (truncate)
s.resize(s.length() - 1);
}
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
return s;
}
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
static std::string
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
PrintType(const llvm::Type *type, bool truncate = false)
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
{
std::string s;
raw_string_ostream rso(s);
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
type->print(rso);
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
rso.flush();
if (truncate)
s.resize(s.length() - 1);
return s;
}
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
IRForTarget::~IRForTarget()
{
}
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
bool
IRForTarget::FixFunctionLinkage(llvm::Function &llvm_function)
{
llvm_function.setLinkage(GlobalValue::ExternalLinkage);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Pulled in a new revision of LLVM/Clang and added several patches. These patches fix a problem where templated types were not being completed the first time they were used, and fix a variety of minor issues I discovered while fixing that problem. One of the previous local patches was resolved in the most recent Clang, so I removed it. The others will be removed in due course. llvm-svn: 144984
2011-11-19 10:54:21 +08:00
std::string name = llvm_function.getName().str();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return true;
}
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
IRForTarget::LookupResult
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
IRForTarget::GetFunctionAddress (llvm::Function *fun,
uint64_t &fun_addr,
lldb_private::ConstString &name,
Constant **&value_ptr)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
fun_addr = LLDB_INVALID_ADDRESS;
name.Clear();
value_ptr = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (fun->isIntrinsic())
{
Intrinsic::ID intrinsic_id = (Intrinsic::ID)fun->getIntrinsicID();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
switch (intrinsic_id)
{
default:
if (log)
log->Printf("Unresolved intrinsic \"%s\"", Intrinsic::getName(intrinsic_id).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Call to unhandled compiler intrinsic '%s'\n", Intrinsic::getName(intrinsic_id).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Correct indentation level for one line. llvm-svn: 212582
2014-07-09 09:10:37 +08:00
return LookupResult::Fail;
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
case Intrinsic::memcpy:
{
static lldb_private::ConstString g_memcpy_str ("memcpy");
name = g_memcpy_str;
}
break;
Two fixes for Objetive-C methods that return struct types. First, I added handling for the memset intrinsic in the IR, which is used to zero out the returned struct. Second, I fixed the object-checking instrumentation to objc_msgSend_stret, and generally tightened up how the object-checking functions get inserted. llvm-svn: 144741
2011-11-16 08:20:50 +08:00
case Intrinsic::memset:
{
static lldb_private::ConstString g_memset_str ("memset");
name = g_memset_str;
}
break;
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
case Intrinsic::dbg_declare:
Fixed a problem where IRForTarget wasn't ignoring dbg_value intrinsics appropriately. <rdar://problem/16504649> llvm-svn: 205825
2014-04-09 08:59:41 +08:00
case Intrinsic::dbg_value:
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
return LookupResult::Ignore;
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (log && name)
log->Printf("Resolved intrinsic name \"%s\"", name.GetCString());
}
else
{
name.SetCStringWithLength (fun->getName().data(), fun->getName().size());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
// Find the address of the function.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
clang::NamedDecl *fun_decl = DeclForGlobal (fun);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (fun_decl)
{
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
if (!m_decl_map->GetFunctionInfo (fun_decl, fun_addr))
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
{
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
std::vector<lldb_private::ConstString> alternates;
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
bool found_it = m_decl_map->GetFunctionAddress (name, fun_addr);
if (!found_it)
{
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
if (log)
log->Printf("Address of function \"%s\" not found.\n", name.GetCString());
// Check for an alternate mangling for names from the standard library.
// For example, "std::basic_string<...>" has an alternate mangling scheme per
// the Itanium C++ ABI.
lldb::ProcessSP process_sp = m_data_allocator.GetTarget()->GetProcessSP();
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
if (process_sp)
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
{
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
lldb_private::CPPLanguageRuntime *cpp_runtime = process_sp->GetCPPLanguageRuntime();
if (cpp_runtime && cpp_runtime->GetAlternateManglings(name, alternates))
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
{
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
for (size_t i = 0; i < alternates.size(); ++i)
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
{
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
const lldb_private::ConstString &alternate_name = alternates[i];
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
if (log)
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
log->Printf("Looking up address of function \"%s\" with alternate name \"%s\"",
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
name.GetCString(), alternate_name.GetCString());
Don't crash if we don't have a process and need to check for alternate manglings. llvm-svn: 238475
2015-05-29 04:06:40 +08:00
if ((found_it = m_decl_map->GetFunctionAddress (alternate_name, fun_addr)))
{
if (log)
log->Printf("Found address of function \"%s\" with alternate name \"%s\"",
name.GetCString(), alternate_name.GetCString());
break;
}
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
}
}
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
if (!found_it)
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
{
<rdar://problem/10998370> Improved the error message when we can find a function in the current program by printing the demangled name. Also added the ability to create lldb_private::Mangled instances with a ConstString when we already have a ConstString for a mangled or demangled name. Also added the ability to call SetValue with a ConstString and also without a boolean to indicate if the string is mangled where we will now auto-detect if the string is mangled. llvm-svn: 160450
2012-07-19 04:47:40 +08:00
lldb_private::Mangled mangled_name(name);
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (m_error_stream)
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
{
[IRForTarget] Strenghten handling of alternate mangling. Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
2015-04-10 02:48:34 +08:00
if (mangled_name.GetMangledName())
Be sure to print out the fully mangled name when we are unable to find a function to call so we can easily look for this symbol if needed. llvm-svn: 180151
2013-04-24 05:48:38 +08:00
m_error_stream->Printf("error: call to a function '%s' ('%s') that is not present in the target\n",
mangled_name.GetName().GetCString(),
mangled_name.GetMangledName().GetCString());
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
else
<rdar://problem/10998370> Improved the error message when we can find a function in the current program by printing the demangled name. Also added the ability to create lldb_private::Mangled instances with a ConstString when we already have a ConstString for a mangled or demangled name. Also added the ability to call SetValue with a ConstString and also without a boolean to indicate if the string is mangled where we will now auto-detect if the string is mangled. llvm-svn: 160450
2012-07-19 04:47:40 +08:00
m_error_stream->Printf("error: call to a function '%s' that is not present in the target\n",
mangled_name.GetName().GetCString());
Added template support when parsing DWARF into types. We can now use STL classes in the expression parser. llvm-svn: 142717
2011-10-22 11:33:13 +08:00
}
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
return LookupResult::Fail;
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
else
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
{
if (!m_decl_map->GetFunctionAddress (name, fun_addr))
{
if (log)
log->Printf ("Metadataless function \"%s\" had no address", name.GetCString());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Call to a symbol-only function '%s' that is not present in the target\n", name.GetCString());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
return LookupResult::Fail;
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Found \"%s\" at 0x%" PRIx64, name.GetCString(), fun_addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
return LookupResult::Success;
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
}
llvm::Constant *
IRForTarget::BuildFunctionPointer (llvm::Type *type,
uint64_t ptr)
{
PointerType *fun_ptr_ty = PointerType::getUnqual(type);
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *fun_addr_int = ConstantInt::get(m_intptr_ty, ptr, false);
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
return ConstantExpr::getIntToPtr(fun_addr_int, fun_ptr_ty);
}
The IRDynamicChecks subsystem was not properly detecting Objective-C method calls because the "lldb.call.realName" metadata was no longer being correctly installed. I fixed this problem. llvm-svn: 143371
2011-11-01 06:11:40 +08:00
void
IRForTarget::RegisterFunctionMetadata(LLVMContext &context,
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
llvm::Value *function_ptr,
The IRDynamicChecks subsystem was not properly detecting Objective-C method calls because the "lldb.call.realName" metadata was no longer being correctly installed. I fixed this problem. llvm-svn: 143371
2011-11-01 06:11:40 +08:00
const char *name)
{
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
for (llvm::User *user : function_ptr->users())
The IRDynamicChecks subsystem was not properly detecting Objective-C method calls because the "lldb.call.realName" metadata was no longer being correctly installed. I fixed this problem. llvm-svn: 143371
2011-11-01 06:11:40 +08:00
{
if (Instruction *user_inst = dyn_cast<Instruction>(user))
{
Fix crash (in optimized builds) due to invalid metadata operand - ConstantDataArray is not a valid MDNode operand - encode function-name strings in metadata by wrapping in an MDString instead - should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/ llvm-svn: 183153
2013-06-04 04:45:54 +08:00
MDString* md_name = MDString::get(context, StringRef(name));
MDNode *metadata = MDNode::get(context, md_name);
The IRDynamicChecks subsystem was not properly detecting Objective-C method calls because the "lldb.call.realName" metadata was no longer being correctly installed. I fixed this problem. llvm-svn: 143371
2011-11-01 06:11:40 +08:00
user_inst->setMetadata("lldb.call.realName", metadata);
}
else
{
RegisterFunctionMetadata (context, user, name);
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
IRForTarget::ResolveFunctionPointers(llvm::Module &llvm_module)
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
for (llvm::Module::iterator fi = llvm_module.begin();
fi != llvm_module.end();
++fi)
{
Function *fun = fi;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
bool is_decl = fun->isDeclaration();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (log)
Pulled in a new revision of LLVM/Clang and added several patches. These patches fix a problem where templated types were not being completed the first time they were used, and fix a variety of minor issues I discovered while fixing that problem. One of the previous local patches was resolved in the most recent Clang, so I removed it. The others will be removed in due course. llvm-svn: 144984
2011-11-19 10:54:21 +08:00
log->Printf("Examining %s function %s", (is_decl ? "declaration" : "non-declaration"), fun->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
if (!is_decl)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (fun->use_empty())
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
continue; // ignore
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
uint64_t addr = LLDB_INVALID_ADDRESS;
lldb_private::ConstString name;
Constant **value_ptr = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
LookupResult result = GetFunctionAddress(fun,
addr,
name,
value_ptr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
switch (result)
{
case LookupResult::Fail:
return false; // GetFunctionAddress reports its own errors
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
case LookupResult::Ignore:
break; // Nothing to do
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
case LookupResult::Success:
{
Constant *value = BuildFunctionPointer(fun->getFunctionType(), addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
RegisterFunctionMetadata (llvm_module.getContext(), fun, name.AsCString());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
if (value_ptr)
*value_ptr = value;
Remove builtin attribute from calls whose targets we replace If we are replacing a function with the nobuiltin attribute, it may be called with the builtin attribute on call sites. Remove any such attributes since it's illegal to have a builtin call to something other than a nobuiltin function. This fixes the current buildbot breakage (where LLDB crashes on "expression new foo(42)"). llvm-svn: 186990
2013-07-24 05:34:03 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
// If we are replacing a function with the nobuiltin attribute, it may
// be called with the builtin attribute on call sites. Remove any such
// attributes since it's illegal to have a builtin call to something
// other than a nobuiltin function.
if (fun->hasFnAttribute(llvm::Attribute::NoBuiltin)) {
llvm::Attribute builtin = llvm::Attribute::get(fun->getContext(), llvm::Attribute::Builtin);
Remove builtin attribute from calls whose targets we replace If we are replacing a function with the nobuiltin attribute, it may be called with the builtin attribute on call sites. Remove any such attributes since it's illegal to have a builtin call to something other than a nobuiltin function. This fixes the current buildbot breakage (where LLDB crashes on "expression new foo(42)"). llvm-svn: 186990
2013-07-24 05:34:03 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
for (auto u : fun->users()) {
if (auto call = dyn_cast<CallInst>(u)) {
call->removeAttribute(AttributeSet::FunctionIndex, builtin);
}
}
Remove builtin attribute from calls whose targets we replace If we are replacing a function with the nobuiltin attribute, it may be called with the builtin attribute on call sites. Remove any such attributes since it's illegal to have a builtin call to something other than a nobuiltin function. This fixes the current buildbot breakage (where LLDB crashes on "expression new foo(42)"). llvm-svn: 186990
2013-07-24 05:34:03 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
fun->replaceAllUsesWith(value);
Remove builtin attribute from calls whose targets we replace If we are replacing a function with the nobuiltin attribute, it may be called with the builtin attribute on call sites. Remove any such attributes since it's illegal to have a builtin call to something other than a nobuiltin function. This fixes the current buildbot breakage (where LLDB crashes on "expression new foo(42)"). llvm-svn: 186990
2013-07-24 05:34:03 +08:00
}
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
break;
Remove builtin attribute from calls whose targets we replace If we are replacing a function with the nobuiltin attribute, it may be called with the builtin attribute on call sites. Remove any such attributes since it's illegal to have a builtin call to something other than a nobuiltin function. This fixes the current buildbot breakage (where LLDB crashes on "expression new foo(42)"). llvm-svn: 186990
2013-07-24 05:34:03 +08:00
}
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
return true;
}
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
clang::NamedDecl *
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
IRForTarget::DeclForGlobal (const GlobalValue *global_val, Module *module)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
{
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
NamedMDNode *named_metadata = module->getNamedMetadata("clang.global.decl.ptrs");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (!named_metadata)
return NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
unsigned num_nodes = named_metadata->getNumOperands();
unsigned node_index;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
for (node_index = 0;
node_index < num_nodes;
++node_index)
{
Fix LLDB build as a result of upstream LLVM changes. llvm-svn: 221378
2014-11-06 02:37:53 +08:00
llvm::MDNode *metadata_node = dyn_cast<llvm::MDNode>(named_metadata->getOperand(node_index));
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (!metadata_node)
return NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (metadata_node->getNumOperands() != 2)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
if (mdconst::dyn_extract_or_null<GlobalValue>(metadata_node->getOperand(0)) != global_val)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
ConstantInt *constant_int = mdconst::dyn_extract<ConstantInt>(metadata_node->getOperand(1));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (!constant_int)
return NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
uintptr_t ptr = constant_int->getZExtValue();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
return reinterpret_cast<clang::NamedDecl *>(ptr);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
return NULL;
}
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
clang::NamedDecl *
IRForTarget::DeclForGlobal (GlobalValue *global_val)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
return DeclForGlobal(global_val, m_module);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::CreateResultVariable (llvm::Function &llvm_function)
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
if (!m_resolve_vars)
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
// Find the result variable. If it doesn't exist, we can give up right here.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
ValueSymbolTable& value_symbol_table = m_module->getValueSymbolTable();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
std::string result_name_str;
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
const char *result_name = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
for (ValueSymbolTable::iterator vi = value_symbol_table.begin(), ve = value_symbol_table.end();
vi != ve;
++vi)
{
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
result_name_str = vi->first().str();
const char *value_name = result_name_str.c_str();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
if (strstr(value_name, "$__lldb_expr_result_ptr") &&
Fixed a problem where we mistook normal result variables for guard variables because the current class or method named contained the letters "GV". llvm-svn: 167327
2012-11-03 06:28:08 +08:00
strncmp(value_name, "_ZGV", 4))
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
{
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
result_name = value_name;
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
m_result_is_pointer = true;
break;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
if (strstr(value_name, "$__lldb_expr_result") &&
Fixed a problem where we mistook normal result variables for guard variables because the current class or method named contained the letters "GV". llvm-svn: 167327
2012-11-03 06:28:08 +08:00
strncmp(value_name, "_ZGV", 4))
Fixed two bugs in the expression parser: - the guard variable for the static result variable was being mistaken for the actual result value, causing IRForTarget to fail - LLVM builtins like memcpy were not being properly resolved; now they are resolved to the corresponding function in the target llvm-svn: 114990
2010-09-29 05:13:03 +08:00
{
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
result_name = value_name;
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
m_result_is_pointer = false;
Fixed two bugs in the expression parser: - the guard variable for the static result variable was being mistaken for the actual result value, causing IRForTarget to fail - LLVM builtins like memcpy were not being properly resolved; now they are resolved to the corresponding function in the target llvm-svn: 114990
2010-09-29 05:13:03 +08:00
break;
}
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
if (!result_name)
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
{
if (log)
log->PutCString("Couldn't find result variable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This reverts r192484, which I really shouldn't have checked in. Apologies. llvm-svn: 192488
2013-10-12 03:44:23 +08:00
return true;
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed two bugs in the expression parser: - the guard variable for the static result variable was being mistaken for the actual result value, causing IRForTarget to fail - LLVM builtins like memcpy were not being properly resolved; now they are resolved to the corresponding function in the target llvm-svn: 114990
2010-09-29 05:13:03 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Result name: \"%s\"", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
Value *result_value = m_module->getNamedValue(result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
if (!result_value)
{
if (log)
log->PutCString("Result variable had no data");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Result variable's name (%s) exists, but not its definition\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Found result in the IR: \"%s\"", PrintValue(result_value, false).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
GlobalVariable *result_global = dyn_cast<GlobalVariable>(result_value);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
if (!result_global)
{
if (log)
log->PutCString("Result variable isn't a GlobalVariable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Result variable (%s) is defined, but is not a global variable\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
clang::NamedDecl *result_decl = DeclForGlobal (result_global);
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (!result_decl)
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
{
if (log)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
log->PutCString("Result variable doesn't have a corresponding Decl");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
m_error_stream->Printf("Internal error [IRForTarget]: Result variable (%s) does not have a corresponding Clang entity\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (log)
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
{
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
std::string decl_desc_str;
raw_string_ostream decl_desc_stream(decl_desc_str);
result_decl->print(decl_desc_stream);
decl_desc_stream.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
log->Printf("Found result decl: \"%s\"", decl_desc_str.c_str());
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
clang::VarDecl *result_var = dyn_cast<clang::VarDecl>(result_decl);
if (!result_var)
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
{
if (log)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
log->PutCString("Result variable Decl isn't a VarDecl");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
m_error_stream->Printf("Internal error [IRForTarget]: Result variable (%s)'s corresponding Clang entity isn't a variable\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
// Get the next available result name from m_decl_map and create the persistent
// variable for it
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
// If the result is an Lvalue, it is emitted as a pointer; see
// ASTResultSynthesizer::SynthesizeBodyResult.
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
if (m_result_is_pointer)
{
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
clang::QualType pointer_qual_type = result_var->getType();
Updated Clang to a version that supports propagating the "virtual" flag when importing a C++ function declaration. Made changes to LLDB to support other changes in Clang. llvm-svn: 124355
2011-01-27 12:42:51 +08:00
const clang::Type *pointer_type = pointer_qual_type.getTypePtr();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit is the result of a general audit of the expression parser to locate instances where dyn_cast<>() and isa<>() are used on types, and replace them with getAs<>() as appropriate. The difference is that dyn_cast<>() and isa<>() are essentially LLVM/Clang's equivalent of RTTI -- that is, they try to downcast the object and return NULL if they cannot -- but getAs<>() can traverse typedefs to perform a semantic cast. llvm-svn: 146537
2011-12-14 09:13:04 +08:00
const clang::PointerType *pointer_pointertype = pointer_type->getAs<clang::PointerType>();
const clang::ObjCObjectPointerType *pointer_objcobjpointertype = pointer_type->getAs<clang::ObjCObjectPointerType>();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added the ability to dereference an Objective-C object pointer to make the result of an expression. LLDB now dumps the ivars of the Objective-C object and all of its parents. This just required fixing a bug where we didn't distinguish between Objective-C object pointers and regular C-style pointers. Also added a testcase to verify that this continues to work. llvm-svn: 146164
2011-12-09 03:04:34 +08:00
if (pointer_pointertype)
{
clang::QualType element_qual_type = pointer_pointertype->getPointeeType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added the ability to dereference an Objective-C object pointer to make the result of an expression. LLDB now dumps the ivars of the Objective-C object and all of its parents. This just required fixing a bug where we didn't distinguish between Objective-C object pointers and regular C-style pointers. Also added a testcase to verify that this continues to work. llvm-svn: 146164
2011-12-09 03:04:34 +08:00
m_result_type = lldb_private::TypeFromParser(element_qual_type.getAsOpaquePtr(),
&result_decl->getASTContext());
}
else if (pointer_objcobjpointertype)
{
clang::QualType element_qual_type = clang::QualType(pointer_objcobjpointertype->getObjectType(), 0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added the ability to dereference an Objective-C object pointer to make the result of an expression. LLDB now dumps the ivars of the Objective-C object and all of its parents. This just required fixing a bug where we didn't distinguish between Objective-C object pointers and regular C-style pointers. Also added a testcase to verify that this continues to work. llvm-svn: 146164
2011-12-09 03:04:34 +08:00
m_result_type = lldb_private::TypeFromParser(element_qual_type.getAsOpaquePtr(),
&result_decl->getASTContext());
}
else
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
{
if (log)
log->PutCString("Expected result to have pointer type, but it did not");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Lvalue result (%s) is not a pointer variable\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
return false;
}
}
else
{
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
m_result_type = lldb_private::TypeFromParser(result_var->getType().getAsOpaquePtr(),
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
&result_decl->getASTContext());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Make a more complete fix for always supplying an execution context when getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-02-12 08:34:25 +08:00
lldb::TargetSP target_sp (m_data_allocator.GetTarget());
Fixed an infinite recursion bug that could happen when using python operating system plug-ins where we would ask the operating system plug-in to update its threads and this would cause the plugin to run an expression which would eventually run IRForTarget::CreateResultVariable() which would try to get the selected thread and cause re-entrant bug. <rdar://problem/19924734> llvm-svn: 230711
2015-02-27 08:12:22 +08:00
lldb_private::ExecutionContext exe_ctx (target_sp, true);
Make a more complete fix for always supplying an execution context when getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-02-12 08:34:25 +08:00
if (m_result_type.GetBitSize(exe_ctx.GetBestExecutionContextScope()) == 0)
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
{
lldb_private::StreamString type_desc_stream;
m_result_type.DumpTypeDescription(&type_desc_stream);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
if (log)
log->Printf("Result type has size 0");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
if (m_error_stream)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
m_error_stream->Printf("Error [IRForTarget]: Size of result type '%s' couldn't be determined\n",
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
type_desc_stream.GetData());
Made IRForTarget error out correctly when it can't complete the result type, preventing crashes later. llvm-svn: 147107
2011-12-22 07:44:05 +08:00
return false;
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (log)
{
lldb_private::StreamString type_desc_stream;
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
m_result_type.DumpTypeDescription(&type_desc_stream);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
log->Printf("Result decl type: \"%s\"", type_desc_stream.GetData());
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_result_name = lldb_private::ConstString("$RESULT_NAME");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
if (log)
<rdar://problem/13421412> Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere. llvm-svn: 177091
2013-03-15 02:31:44 +08:00
log->Printf("Creating a new result global: \"%s\" with size 0x%" PRIx64,
This commit completes the rearchitecting of ClangASTSource to allow variables in the persistent variable store to know how to complete themselves from debug information. That fixes a variety of bugs during dematerialization of expression results and also makes persistent variable and result variables ($foo, $4, ...) more useful. I have also added logging improvements that make it much easier to figure out how types are moving from place to place, and made some checking a little more aggressive. The commit includes patches to Clang which are currently being integrated into Clang proper; once these fixes are in Clang top-of-tree, these patches will be removed. The patches don't fix API; rather, they fix some internal bugs in Clang's ASTImporter that were exposed when LLDB was moving types from place to place multiple times. llvm-svn: 144969
2011-11-18 11:28:09 +08:00
m_result_name.GetCString(),
Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
2015-01-28 08:07:51 +08:00
m_result_type.GetByteSize(nullptr));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
// Construct a new result global and set up its metadata
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
GlobalVariable *new_result_global = new GlobalVariable((*m_module),
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
result_global->getType()->getElementType(),
false, /* not constant */
GlobalValue::ExternalLinkage,
NULL, /* no initializer */
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
m_result_name.GetCString ());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
// It's too late in compilation to create a new VarDecl for this, but we don't
// need to. We point the metadata at the old VarDecl. This creates an odd
// anomaly: a variable with a Value whose name is something like $0 and a
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
// Decl whose name is $__lldb_expr_result. This condition is handled in
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
// ClangExpressionDeclMap::DoMaterialize, and the name of the variable is
// fixed up.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
ConstantInt *new_constant_int = ConstantInt::get(llvm::Type::getInt64Ty(m_module->getContext()),
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
reinterpret_cast<uint64_t>(result_decl),
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
false);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
llvm::Metadata *values[2];
values[0] = ConstantAsMetadata::get(new_result_global);
values[1] = ConstantAsMetadata::get(new_constant_int);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
ArrayRef<Metadata *> value_ref(values, 2);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
MDNode *persistent_global_md = MDNode::get(m_module->getContext(), value_ref);
NamedMDNode *named_metadata = m_module->getNamedMetadata("clang.global.decl.ptrs");
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
named_metadata->addOperand(persistent_global_md);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Replacing \"%s\" with \"%s\"",
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
PrintValue(result_global).c_str(),
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
PrintValue(new_result_global).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (result_global->use_empty())
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
{
// We need to synthesize a store for this variable, because otherwise
// there's nothing to put into its equivalent persistent variable.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
BasicBlock &entry_block(llvm_function.getEntryBlock());
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
Instruction *first_entry_instruction(entry_block.getFirstNonPHIOrDbg());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
if (!first_entry_instruction)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
if (!result_global->hasInitializer())
{
if (log)
log->Printf("Couldn't find initializer for unused variable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Result variable (%s) has no writes and no initializer\n", result_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
Constant *initializer = result_global->getInitializer();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed an excessive ctor issue. Patch from Kirk Beitz / Jai Menon. llvm-svn: 124928
2011-02-05 10:28:58 +08:00
StoreInst *synthesized_store = new StoreInst(initializer,
new_result_global,
first_entry_instruction);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Synthesized result store \"%s\"\n", PrintValue(synthesized_store).c_str());
Fixed a bug where we did not handle constant expressions correctly. These produced a result variable with an initializer but no store instruction, and the store instruction was as a result never rewritten to become a store to a persistent variable. Now if the result variable has an initializer but is never used, we generate a (redundant) store instruction for it, which is then later rewritten into a (useful) store to the persistent result variable. llvm-svn: 113300
2010-09-08 06:43:19 +08:00
}
else
{
result_global->replaceAllUsesWith(new_result_global);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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_decl_map->AddPersistentVariable(result_decl,
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
m_result_name,
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_type,
true,
m_result_is_pointer))
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
result_global->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
return true;
}
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RewriteObjCConstString (llvm::GlobalVariable *ns_str,
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
llvm::GlobalVariable *cstr)
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *ns_str_ty = ns_str->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *i8_ptr_ty = Type::getInt8PtrTy(m_module->getContext());
Type *i32_ty = Type::getInt32Ty(m_module->getContext());
Type *i8_ty = Type::getInt8Ty(m_module->getContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!m_CFStringCreateWithBytes)
{
lldb::addr_t CFStringCreateWithBytes_addr;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
static lldb_private::ConstString g_CFStringCreateWithBytes_str ("CFStringCreateWithBytes");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!m_decl_map->GetFunctionAddress (g_CFStringCreateWithBytes_str, CFStringCreateWithBytes_addr))
{
if (log)
log->PutCString("Couldn't find CFStringCreateWithBytes in the target");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Rewriting an Objective-C constant string requires CFStringCreateWithBytes\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Found CFStringCreateWithBytes at 0x%" PRIx64, CFStringCreateWithBytes_addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
// Build the function type:
//
// CFStringRef CFStringCreateWithBytes (
// CFAllocatorRef alloc,
// const UInt8 *bytes,
// CFIndex numBytes,
// CFStringEncoding encoding,
// Boolean isExternalRepresentation
// );
//
// We make the following substitutions:
//
// CFStringRef -> i8*
// CFAllocatorRef -> i8*
// UInt8 * -> i8*
// CFIndex -> long (i32 or i64, as appropriate; we ask the module for its pointer size for now)
// CFStringEncoding -> i32
// Boolean -> i8
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *arg_type_array[5];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
arg_type_array[0] = i8_ptr_ty;
arg_type_array[1] = i8_ptr_ty;
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
arg_type_array[2] = m_intptr_ty;
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
arg_type_array[3] = i32_ty;
arg_type_array[4] = i8_ty;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
ArrayRef<Type *> CFSCWB_arg_types(arg_type_array, 5);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
llvm::Type *CFSCWB_ty = FunctionType::get(ns_str_ty, CFSCWB_arg_types, false);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
// Build the constant containing the pointer to the function
PointerType *CFSCWB_ptr_ty = PointerType::getUnqual(CFSCWB_ty);
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *CFSCWB_addr_int = ConstantInt::get(m_intptr_ty, CFStringCreateWithBytes_addr, false);
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
m_CFStringCreateWithBytes = ConstantExpr::getIntToPtr(CFSCWB_addr_int, CFSCWB_ptr_ty);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
ConstantDataSequential *string_array = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
if (cstr)
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
string_array = dyn_cast<ConstantDataSequential>(cstr->getInitializer());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Constant *alloc_arg = Constant::getNullValue(i8_ptr_ty);
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
Constant *bytes_arg = cstr ? ConstantExpr::getBitCast(cstr, i8_ptr_ty) : Constant::getNullValue(i8_ptr_ty);
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *numBytes_arg = ConstantInt::get(m_intptr_ty, cstr ? string_array->getNumElements() - 1 : 0, false);
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Constant *encoding_arg = ConstantInt::get(i32_ty, 0x0600, false); /* 0x0600 is kCFStringEncodingASCII */
Constant *isExternal_arg = ConstantInt::get(i8_ty, 0x0, false); /* 0x0 is false */
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Value *argument_array[5];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
argument_array[0] = alloc_arg;
argument_array[1] = bytes_arg;
argument_array[2] = numBytes_arg;
argument_array[3] = encoding_arg;
argument_array[4] = isExternal_arg;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
ArrayRef <Value *> CFSCWB_arguments(argument_array, 5);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
FunctionValueCache CFSCWB_Caller ([this, &CFSCWB_arguments] (llvm::Function *function)->llvm::Value * {
return CallInst::Create(m_CFStringCreateWithBytes,
CFSCWB_arguments,
"CFStringCreateWithBytes",
llvm::cast<Instruction>(m_entry_instruction_finder.GetValue(function)));
});
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!UnfoldConstant(ns_str, CFSCWB_Caller, m_entry_instruction_finder))
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
{
if (log)
log->PutCString("Couldn't replace the NSString with the result of the call");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Couldn't replace an Objective-C constant string with a dynamic string\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
ns_str->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return true;
}
bool
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
IRForTarget::RewriteObjCConstStrings()
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
ValueSymbolTable& value_symbol_table = m_module->getValueSymbolTable();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
for (ValueSymbolTable::iterator vi = value_symbol_table.begin(), ve = value_symbol_table.end();
vi != ve;
++vi)
{
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
std::string value_name = vi->first().str();
const char *value_name_cstr = value_name.c_str();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
if (strstr(value_name_cstr, "_unnamed_cfstring_"))
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
{
Value *nsstring_value = vi->second;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
GlobalVariable *nsstring_global = dyn_cast<GlobalVariable>(nsstring_value);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!nsstring_global)
{
if (log)
log->PutCString("NSString variable is not a GlobalVariable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string is not a global variable\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!nsstring_global->hasInitializer())
{
if (log)
log->PutCString("NSString variable does not have an initializer");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string does not have an initializer\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
ConstantStruct *nsstring_struct = dyn_cast<ConstantStruct>(nsstring_global->getInitializer());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!nsstring_struct)
{
if (log)
log->PutCString("NSString variable's initializer is not a ConstantStruct");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string is not a structure constant\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
// We expect the following structure:
//
// struct {
// int *isa;
// int flags;
// char *str;
// long length;
// };
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (nsstring_struct->getNumOperands() != 4)
{
if (log)
log->Printf("NSString variable's initializer structure has an unexpected number of members. Should be 4, is %d", nsstring_struct->getNumOperands());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: The struct for an Objective-C constant string is not as expected\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Constant *nsstring_member = nsstring_struct->getOperand(2);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!nsstring_member)
{
if (log)
log->PutCString("NSString initializer's str element was empty");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string does not have a string initializer\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
ConstantExpr *nsstring_expr = dyn_cast<ConstantExpr>(nsstring_member);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!nsstring_expr)
{
if (log)
log->PutCString("NSString initializer's str element is not a ConstantExpr");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer is not constant\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (nsstring_expr->getOpcode() != Instruction::GetElementPtr)
{
if (log)
log->Printf("NSString initializer's str element is not a GetElementPtr expression, it's a %s", nsstring_expr->getOpcodeName());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Constant *nsstring_cstr = nsstring_expr->getOperand(0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
GlobalVariable *cstr_global = dyn_cast<GlobalVariable>(nsstring_cstr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!cstr_global)
{
if (log)
log->PutCString("NSString initializer's str element is not a GlobalVariable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer doesn't point to a global\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!cstr_global->hasInitializer())
{
if (log)
log->PutCString("NSString initializer's str element does not have an initializer");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer doesn't point to initialized data\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
/*
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!cstr_array)
{
if (log)
log->PutCString("NSString initializer's str element is not a ConstantArray");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer doesn't point to an array\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!cstr_array->isCString())
{
if (log)
log->PutCString("NSString initializer's str element is not a C string array");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: An Objective-C constant string's string initializer doesn't point to a C string\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
*/
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
ConstantDataArray *cstr_array = dyn_cast<ConstantDataArray>(cstr_global->getInitializer());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (log)
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
{
if (cstr_array)
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
log->Printf("Found NSString constant %s, which contains \"%s\"", value_name_cstr, cstr_array->getAsString().str().c_str());
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
else
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
log->Printf("Found NSString constant %s, which contains \"\"", value_name_cstr);
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes for two bugs: - Objective-C constant strings were being NULL-terminated erroneously. - Empty Objective-C constant strings were not being generated correctly. Also added the template for a test of these fixes. llvm-svn: 125314
2011-02-11 06:17:53 +08:00
if (!cstr_array)
cstr_global = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!RewriteObjCConstString(nsstring_global, cstr_global))
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (log)
log->PutCString("Error rewriting the constant string");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// We don't print an error message here because RewriteObjCConstString has done so for us.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
for (ValueSymbolTable::iterator vi = value_symbol_table.begin(), ve = value_symbol_table.end();
vi != ve;
++vi)
{
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
std::string value_name = vi->first().str();
const char *value_name_cstr = value_name.c_str();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
if (!strcmp(value_name_cstr, "__CFConstantStringClassReference"))
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
{
GlobalVariable *gv = dyn_cast<GlobalVariable>(vi->second);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!gv)
{
if (log)
log->PutCString("__CFConstantStringClassReference is not a global variable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Found a CFConstantStringClassReference, but it is not a global object\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
gv->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
break;
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return true;
}
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
static bool IsObjCSelectorRef (Value *value)
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
{
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
GlobalVariable *global_variable = dyn_cast<GlobalVariable>(value);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix selectors not being objc-uniquified in the expression parser after a recent renaming in clang (clang change for revision 221451). This broke all objective C expressions in LLDB. llvm-svn: 221632
2014-11-11 05:45:59 +08:00
if (!global_variable || !global_variable->hasName() || !global_variable->getName().startswith("OBJC_SELECTOR_REFERENCES_"))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return true;
}
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// This function does not report errors; its callers are responsible.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RewriteObjCSelector (Instruction* selector_load)
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
LoadInst *load = dyn_cast<LoadInst>(selector_load);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!load)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Unpack the message name from the selector. In LLVM IR, an objc_msgSend gets represented as
//
Fix comments to match the current reality. llvm-svn: 221633
2014-11-11 05:48:12 +08:00
// %tmp = load i8** @"OBJC_SELECTOR_REFERENCES_" ; <i8*>
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// %call = call i8* (i8*, i8*, ...)* @objc_msgSend(i8* %obj, i8* %tmp, ...) ; <i8*>
//
// where %obj is the object pointer and %tmp is the selector.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
//
Fix comments to match the current reality. llvm-svn: 221633
2014-11-11 05:48:12 +08:00
// @"OBJC_SELECTOR_REFERENCES_" is a pointer to a character array called @"\01L_OBJC_llvm_moduleETH_VAR_NAllvm_moduleE_".
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
// @"\01L_OBJC_llvm_moduleETH_VAR_NAllvm_moduleE_" contains the string.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Find the pointer's initializer (a ConstantExpr with opcode GetElementPtr) and get the string from its target
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
GlobalVariable *_objc_selector_references_ = dyn_cast<GlobalVariable>(load->getPointerOperand());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!_objc_selector_references_ || !_objc_selector_references_->hasInitializer())
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
Constant *osr_initializer = _objc_selector_references_->getInitializer();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
ConstantExpr *osr_initializer_expr = dyn_cast<ConstantExpr>(osr_initializer);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!osr_initializer_expr || osr_initializer_expr->getOpcode() != Instruction::GetElementPtr)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
Value *osr_initializer_base = osr_initializer_expr->getOperand(0);
if (!osr_initializer_base)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Find the string's initializer (a ConstantArray) and get the string from it
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
GlobalVariable *_objc_meth_var_name_ = dyn_cast<GlobalVariable>(osr_initializer_base);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!_objc_meth_var_name_ || !_objc_meth_var_name_->hasInitializer())
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
Constant *omvn_initializer = _objc_meth_var_name_->getInitializer();
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
ConstantDataArray *omvn_initializer_array = dyn_cast<ConstantDataArray>(omvn_initializer);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!omvn_initializer_array->isString())
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
std::string omvn_initializer_string = omvn_initializer_array->getAsString();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Found Objective-C selector reference \"%s\"", omvn_initializer_string.c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Construct a call to sel_registerName
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!m_sel_registerName)
{
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
lldb::addr_t sel_registerName_addr;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
static lldb_private::ConstString g_sel_registerName_str ("sel_registerName");
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
if (!m_decl_map->GetFunctionAddress (g_sel_registerName_str, sel_registerName_addr))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem where function calls on i386 weren't being generated correctly. Also added a messy way to single-step through expressions that I will improve soon. llvm-svn: 117342
2010-10-26 08:31:56 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Found sel_registerName at 0x%" PRIx64, sel_registerName_addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Build the function type: struct objc_selector *sel_registerName(uint8_t*)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// The below code would be "more correct," but in actuality what's required is uint8_t*
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
//Type *sel_type = StructType::get(m_module->getContext());
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
//Type *sel_ptr_type = PointerType::getUnqual(sel_type);
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *sel_ptr_type = Type::getInt8PtrTy(m_module->getContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *type_array[1];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
type_array[0] = llvm::Type::getInt8PtrTy(m_module->getContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
ArrayRef<Type *> srN_arg_types(type_array, 1);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
llvm::Type *srN_type = FunctionType::get(sel_ptr_type, srN_arg_types, false);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Build the constant containing the pointer to the function
PointerType *srN_ptr_ty = PointerType::getUnqual(srN_type);
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *srN_addr_int = ConstantInt::get(m_intptr_ty, sel_registerName_addr, false);
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
m_sel_registerName = ConstantExpr::getIntToPtr(srN_addr_int, srN_ptr_ty);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Value *argument_array[1];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
Constant *omvn_pointer = ConstantExpr::getBitCast(_objc_meth_var_name_, Type::getInt8PtrTy(m_module->getContext()));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
argument_array[0] = omvn_pointer;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
ArrayRef<Value *> srN_arguments(argument_array, 1);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
CallInst *srN_call = CallInst::Create(m_sel_registerName,
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
srN_arguments,
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
"sel_registerName",
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
selector_load);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
// Replace the load with the call in all users
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
selector_load->replaceAllUsesWith(srN_call);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
selector_load->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return true;
}
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RewriteObjCSelectors (BasicBlock &basic_block)
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
BasicBlock::iterator ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
typedef SmallVector <Instruction*, 2> InstrList;
typedef InstrList::iterator InstrIterator;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
InstrList selector_loads;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
for (ii = basic_block.begin();
ii != basic_block.end();
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
++ii)
{
Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (LoadInst *load = dyn_cast<LoadInst>(&inst))
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
if (IsObjCSelectorRef(load->getPointerOperand()))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
selector_loads.push_back(&inst);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
InstrIterator iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
for (iter = selector_loads.begin();
iter != selector_loads.end();
++iter)
{
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!RewriteObjCSelector(*iter))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
{
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't change a static reference to an Objective-C selector to a dynamic reference\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The implementation of categories is now synchronization safe Code cleanup: - The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...) are contained. The wrapper code always remains in Debugger.{h|cpp} - Several leftover fields, methods and comments from previous design choices have been removed type category subcommands (enable, disable, delete) now can take a list of category names as input - for type category enable, saying "enable A B C" is the same as saying enable C enable B enable A (the ordering is relevant in enabling categories, and it is expected that a user typing enable A B C wants to look into category A, then into B, then into C and not the other way round) - for the other two commands, the order is not really relevant (however, the same inverted ordering is used for consistency) llvm-svn: 135494
2011-07-20 02:03:25 +08:00
if (log)
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
log->PutCString("Couldn't rewrite a reference to an Objective-C selector");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return false;
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return true;
}
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// This function does not report errors; its callers are responsible.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RewritePersistentAlloc (llvm::Instruction *persistent_alloc)
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
AllocaInst *alloc = dyn_cast<AllocaInst>(persistent_alloc);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Revert "Update for LLVM API change in r221024" This reverts commit r221073 to match upstream revert in r221711. llvm-svn: 221749
2014-11-12 09:59:53 +08:00
MDNode *alloc_md = alloc->getMetadata("clang.decl.ptr");
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
if (!alloc_md || !alloc_md->getNumOperands())
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
ConstantInt *constant_int = mdconst::dyn_extract<ConstantInt>(alloc_md->getOperand(0));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
if (!constant_int)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
// We attempt to register this as a new persistent variable with the DeclMap.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
uintptr_t ptr = constant_int->getZExtValue();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
clang::VarDecl *decl = reinterpret_cast<clang::VarDecl *>(ptr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
lldb_private::TypeFromParser result_decl_type (decl->getType().getAsOpaquePtr(),
&decl->getASTContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
StringRef decl_name (decl->getName());
lldb_private::ConstString persistent_variable_name (decl_name.data(), decl_name.size());
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
if (!m_decl_map->AddPersistentVariable(decl, persistent_variable_name, result_decl_type, false, false))
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
GlobalVariable *persistent_global = new GlobalVariable((*m_module),
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
alloc->getType(),
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
false, /* not constant */
GlobalValue::ExternalLinkage,
NULL, /* no initializer */
alloc->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
// What we're going to do here is make believe this was a regular old external
// variable. That means we need to make the metadata valid.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a potential crash if a metadata category we write into doesn't already exist. <rdar://problem/11775508> llvm-svn: 159700
2012-07-04 09:26:26 +08:00
NamedMDNode *named_metadata = m_module->getOrInsertNamedMetadata("clang.global.decl.ptrs");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
llvm::Metadata *values[2];
values[0] = ConstantAsMetadata::get(persistent_global);
values[1] = ConstantAsMetadata::get(constant_int);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix compilation failures resulting from the llvm Metadata refactor. Patch by Duncan P. N. Exon Smith llvm-svn: 223844
2014-12-10 06:29:47 +08:00
ArrayRef<llvm::Metadata *> value_ref(values, 2);
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
MDNode *persistent_global_md = MDNode::get(m_module->getContext(), value_ref);
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
named_metadata->addOperand(persistent_global_md);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
// Now, since the variable is a pointer variable, we will drop in a load of that
// pointer variable.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
LoadInst *persistent_load = new LoadInst (persistent_global, "", alloc);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
if (log)
log->Printf("Replacing \"%s\" with \"%s\"",
PrintValue(alloc).c_str(),
PrintValue(persistent_load).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
alloc->replaceAllUsesWith(persistent_load);
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
alloc->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
return true;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RewritePersistentAllocs(llvm::BasicBlock &basic_block)
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
{
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
if (!m_resolve_vars)
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
BasicBlock::iterator ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
typedef SmallVector <Instruction*, 2> InstrList;
typedef InstrList::iterator InstrIterator;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
InstrList pvar_allocs;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
for (ii = basic_block.begin();
ii != basic_block.end();
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
++ii)
{
Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
if (AllocaInst *alloc = dyn_cast<AllocaInst>(&inst))
Added a safeguard to ensure that the user does not create variables that override persistent result variables. llvm-svn: 124001
2011-01-22 06:30:25 +08:00
{
llvm::StringRef alloc_name = alloc->getName();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a safeguard to ensure that the user does not create variables that override persistent result variables. llvm-svn: 124001
2011-01-22 06:30:25 +08:00
if (alloc_name.startswith("$") &&
!alloc_name.startswith("$__lldb"))
{
if (alloc_name.find_first_of("0123456789") == 1)
{
if (log)
log->Printf("Rejecting a numeric persistent variable.");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Names starting with $0, $1, ... are reserved for use as result names\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a safeguard to ensure that the user does not create variables that override persistent result variables. llvm-svn: 124001
2011-01-22 06:30:25 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
pvar_allocs.push_back(alloc);
Added a safeguard to ensure that the user does not create variables that override persistent result variables. llvm-svn: 124001
2011-01-22 06:30:25 +08:00
}
}
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
InstrIterator iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
for (iter = pvar_allocs.begin();
iter != pvar_allocs.end();
++iter)
{
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!RewritePersistentAlloc(*iter))
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
{
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't rewrite the creation of a persistent variable\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The implementation of categories is now synchronization safe Code cleanup: - The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...) are contained. The wrapper code always remains in Debugger.{h|cpp} - Several leftover fields, methods and comments from previous design choices have been removed type category subcommands (enable, disable, delete) now can take a list of category names as input - for type category enable, saying "enable A B C" is the same as saying enable C enable B enable A (the ordering is relevant in enabling categories, and it is expected that a user typing enable A B C wants to look into category A, then into B, then into C and not the other way round) - for the other two commands, the order is not really relevant (however, the same inverted ordering is used for consistency) llvm-svn: 135494
2011-07-20 02:03:25 +08:00
if (log)
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
log->PutCString("Couldn't rewrite the creation of a persistent variable");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
return false;
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
return true;
}
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
bool
IRForTarget::MaterializeInitializer (uint8_t *data, Constant *initializer)
{
if (!initializer)
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (log && log->GetVerbose())
Fix -Wformat-pedantic warnings llvm-svn: 234429
2015-04-09 04:23:52 +08:00
log->Printf(" MaterializeInitializer(%p, %s)", (void *)data, PrintValue(initializer).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
Type *initializer_type = initializer->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (ConstantInt *int_initializer = dyn_cast<ConstantInt>(initializer))
{
memcpy (data, int_initializer->getValue().getRawData(), m_target_data->getTypeStoreSize(initializer_type));
return true;
}
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
else if (ConstantDataArray *array_initializer = dyn_cast<ConstantDataArray>(initializer))
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
{
if (array_initializer->isString())
{
std::string array_initializer_string = array_initializer->getAsString();
memcpy (data, array_initializer_string.c_str(), m_target_data->getTypeStoreSize(initializer_type));
}
else
{
ArrayType *array_initializer_type = array_initializer->getType();
Type *array_element_type = array_initializer_type->getElementType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
size_t element_size = m_target_data->getTypeAllocSize(array_element_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Sort out a number of mismatched integer types in order to cut down the number of compiler warnings. llvm-svn: 184333
2013-06-20 03:04:53 +08:00
for (unsigned i = 0; i < array_initializer->getNumOperands(); ++i)
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
{
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
Value *operand_value = array_initializer->getOperand(i);
Constant *operand_constant = dyn_cast<Constant>(operand_value);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
if (!operand_constant)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
if (!MaterializeInitializer(data + (i * element_size), operand_constant))
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
return false;
}
}
return true;
}
else if (ConstantStruct *struct_initializer = dyn_cast<ConstantStruct>(initializer))
{
StructType *struct_initializer_type = struct_initializer->getType();
const StructLayout *struct_layout = m_target_data->getStructLayout(struct_initializer_type);
Sort out a number of mismatched integer types in order to cut down the number of compiler warnings. llvm-svn: 184333
2013-06-20 03:04:53 +08:00
for (unsigned i = 0;
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
i < struct_initializer->getNumOperands();
++i)
{
if (!MaterializeInitializer(data + struct_layout->getElementOffset(i), struct_initializer->getOperand(i)))
return false;
}
return true;
}
Fixed expression parser handling of empty strings. <rdar://problem/12977827> llvm-svn: 180215
2013-04-25 03:50:12 +08:00
else if (isa<ConstantAggregateZero>(initializer))
{
memset(data, 0, m_target_data->getTypeStoreSize(initializer_type));
return true;
}
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
return false;
}
bool
IRForTarget::MaterializeInternalVariable (GlobalVariable *global_variable)
{
if (GlobalVariable::isExternalLinkage(global_variable->getLinkage()))
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where the variable-resolution code would occasionally try to resolve the placeholder variable used for static data allocation. llvm-svn: 144677
2011-11-16 03:13:54 +08:00
if (global_variable == m_reloc_placeholder)
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
uint64_t offset = m_data_allocator.GetStream().GetSize();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
llvm::Type *variable_type = global_variable->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
Constant *initializer = global_variable->getInitializer();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
llvm::Type *initializer_type = initializer->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
size_t size = m_target_data->getTypeAllocSize(initializer_type);
Minor fixes for ARM/iOS targets: - On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
2012-06-09 06:20:41 +08:00
size_t align = m_target_data->getPrefTypeAlignment(initializer_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Minor fixes for ARM/iOS targets: - On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
2012-06-09 06:20:41 +08:00
const size_t mask = (align - 1);
uint64_t aligned_offset = (offset + mask) & ~mask;
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator.GetStream().PutNHex8(aligned_offset - offset, 0);
Minor fixes for ARM/iOS targets: - On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
2012-06-09 06:20:41 +08:00
offset = aligned_offset;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
lldb_private::DataBufferHeap data(size, '\0');
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (initializer)
if (!MaterializeInitializer(data.GetBytes(), initializer))
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator.GetStream().Write(data.GetBytes(), data.GetByteSize());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
Constant *new_pointer = BuildRelocation(variable_type, offset);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
global_variable->replaceAllUsesWith(new_pointer);
global_variable->eraseFromParent();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
return true;
}
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// This function does not report errors; its callers are responsible.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::MaybeHandleVariable (Value *llvm_value_ptr)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
if (log)
Fixed a bug in which the SEL type was being resolved wrongly as the target of a pointer rather than the SEL pointer itself. This caused incorrect behavior when dealing with Objective-C selector variables. llvm-svn: 121048
2010-12-07 06:16:55 +08:00
log->Printf("MaybeHandleVariable (%s)", PrintValue(llvm_value_ptr).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
if (ConstantExpr *constant_expr = dyn_cast<ConstantExpr>(llvm_value_ptr))
Set a CodeGenOption in Clang to inhibit insertion of profiling code into expressions. Modified IRForTarget to emit array and record member accesses correctly. (Reading and writing both work.) llvm-svn: 110088
2010-08-03 08:23:29 +08:00
{
Added support for accessing members of C++ objects, including superclass members. This involved ensuring that access control was ignored, and ensuring that the operands of BitCasts were properly scanned for variables that needed importing. Also laid the groundwork for declaring objects of custom types; however, this functionality is disabled for now because of a potential loop in ASTImporter. llvm-svn: 110174
2010-08-04 09:02:13 +08:00
switch (constant_expr->getOpcode())
Set a CodeGenOption in Clang to inhibit insertion of profiling code into expressions. Modified IRForTarget to emit array and record member accesses correctly. (Reading and writing both work.) llvm-svn: 110088
2010-08-03 08:23:29 +08:00
{
Added support for accessing members of C++ objects, including superclass members. This involved ensuring that access control was ignored, and ensuring that the operands of BitCasts were properly scanned for variables that needed importing. Also laid the groundwork for declaring objects of custom types; however, this functionality is disabled for now because of a potential loop in ASTImporter. llvm-svn: 110174
2010-08-04 09:02:13 +08:00
default:
break;
case Instruction::GetElementPtr:
case Instruction::BitCast:
Set a CodeGenOption in Clang to inhibit insertion of profiling code into expressions. Modified IRForTarget to emit array and record member accesses correctly. (Reading and writing both work.) llvm-svn: 110088
2010-08-03 08:23:29 +08:00
Value *s = constant_expr->getOperand(0);
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!MaybeHandleVariable(s))
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
return false;
Set a CodeGenOption in Clang to inhibit insertion of profiling code into expressions. Modified IRForTarget to emit array and record member accesses correctly. (Reading and writing both work.) llvm-svn: 110088
2010-08-03 08:23:29 +08:00
}
}
Eliminated a redundant code path. llvm-svn: 120834
2010-12-04 03:51:05 +08:00
else if (GlobalVariable *global_variable = dyn_cast<GlobalVariable>(llvm_value_ptr))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
{
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (!GlobalValue::isExternalLinkage(global_variable->getLinkage()))
return MaterializeInternalVariable(global_variable);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
clang::NamedDecl *named_decl = DeclForGlobal(global_variable);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (!named_decl)
{
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
if (IsObjCSelectorRef(llvm_value_ptr))
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem in which non-external variables (for example, string literals) were being flagged erroneously as undefined external variables. llvm-svn: 120972
2010-12-06 08:56:39 +08:00
if (!global_variable->hasExternalLinkage())
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Found global variable \"%s\" without metadata", global_variable->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for rewriting objc_msgSend so we can call Objective-C methods from expressions. Also added some more logging to the function-calling thread plan so that we can see the registers when a function finishes. Also documented things maybe a bit better. llvm-svn: 109938
2010-07-31 09:32:05 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
std::string name (named_decl->getName().str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
clang::ValueDecl *value_decl = dyn_cast<clang::ValueDecl>(named_decl);
if (value_decl == NULL)
Wrote the code that looks at a context to see if the variables in that context allow a particular JIT compiled expression to run in that context. llvm-svn: 108485
2010-07-16 08:09:46 +08:00
return false;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
lldb_private::ClangASTType clang_type(&value_decl->getASTContext(), value_decl->getType());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Audited the expression parser to find uninitialized pointers. Some of the spots are obviously initialized later, but it's better just to NULL the pointers out at initialization to make the code more robust when exposed to later changes. llvm-svn: 134670
2011-07-08 08:39:14 +08:00
const Type *value_type = NULL;
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
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
if (name[0] == '$')
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
{
// The $__lldb_expr_result name indicates the the return value has allocated as
// a static variable. Per the comment at ASTResultSynthesizer::SynthesizeBodyResult,
// accesses to this static variable need to be redirected to the result of dereferencing
// a pointer that is passed in as one of the arguments.
//
// Consequently, when reporting the size of the type, we report a pointer type pointing
// to the type of $__lldb_expr_result, not the type itself.
Fixed handling of explicitly-declared persistent variables. llvm-svn: 123398
2011-01-14 05:23:32 +08:00
//
// We also do this for any user-declared persistent variables.
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
clang_type = clang_type.GetPointerType();
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
value_type = PointerType::get(global_variable->getType(), 0);
}
else
{
value_type = global_variable->getType();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
2015-01-28 08:07:51 +08:00
const uint64_t value_size = clang_type.GetByteSize(nullptr);
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t value_alignment = (clang_type.GetTypeBitAlign() + 7ull) / 8ull;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +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
{
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
log->Printf("Type of \"%s\" is [clang \"%s\", llvm \"%s\"] [size %" PRIu64 ", align %" PRIu64 "]",
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
name.c_str(),
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
clang_type.GetQualType().getAsString().c_str(),
PrintType(value_type).c_str(),
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
value_size,
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
value_alignment);
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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored ClangExpressionDeclMap to use ClangExpressionVariables for found external variables as well as for struct members, replacing the Tuple and StructMember data structures. llvm-svn: 111859
2010-08-24 07:09:38 +08:00
if (named_decl && !m_decl_map->AddValueToStruct(named_decl,
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
lldb_private::ConstString (name.c_str()),
llvm_value_ptr,
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
value_size,
Added support for locating a function that is referenced in the IR. We don't yet support updating the call to that function. llvm-svn: 109483
2010-07-27 10:07:53 +08:00
value_alignment))
Fixed a bug where named constants were being treated as externals, causing problems when we tried to look their locations up in the debug info. For example: expr char c[] = "foo"; c[0] would terminate when trying to find c in the debug information, despite the fact that c was defined inside the expression. llvm-svn: 136629
2011-08-02 01:41:38 +08:00
{
if (!global_variable->hasExternalLinkage())
return true;
Handle C++ static variables in the expression parser. <rdar://problem/13631469> llvm-svn: 179304
2013-04-12 01:57:16 +08:00
else if (HandleSymbol (global_variable))
return true;
Fixed a bug where named constants were being treated as externals, causing problems when we tried to look their locations up in the debug info. For example: expr char c[] = "foo"; c[0] would terminate when trying to find c in the debug information, despite the fact that c was defined inside the expression. llvm-svn: 136629
2011-08-02 01:41:38 +08:00
else
return false;
}
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
}
Removed a compiler warning. llvm-svn: 120788
2010-12-03 11:02:31 +08:00
else if (dyn_cast<llvm::Function>(llvm_value_ptr))
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
{
if (log)
log->Printf("Function pointers aren't handled right now");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return true;
}
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// This function does not report errors; its callers are responsible.
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::HandleSymbol (Value *symbol)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
lldb_private::ConstString name(symbol->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made symbol lookup in the expression parser more robust: - Now a client can specify what kind of symbols are needed; notably, this allows looking up Objective-C class symbols specifically. - In the class of symbols being looked up, if one is non-NULL and others are NULL, LLDB now prefers the non-NULL one. llvm-svn: 145554
2011-12-01 10:04:16 +08:00
lldb::addr_t symbol_addr = m_decl_map->GetSymbolAddress (name, lldb::eSymbolTypeAny);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed an issue for ARM where data symbols would alway return invalid addresses. llvm-svn: 133684
2011-06-23 12:25:29 +08:00
if (symbol_addr == LLDB_INVALID_ADDRESS)
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
{
if (log)
log->Printf ("Symbol \"%s\" had no address", name.GetCString());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
return false;
}
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Found \"%s\" at 0x%" PRIx64, name.GetCString(), symbol_addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *symbol_type = symbol->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *symbol_addr_int = ConstantInt::get(m_intptr_ty, symbol_addr, false);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
Value *symbol_addr_ptr = ConstantExpr::getIntToPtr(symbol_addr_int, symbol_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
if (log)
log->Printf("Replacing %s with %s", PrintValue(symbol).c_str(), PrintValue(symbol_addr_ptr).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
symbol->replaceAllUsesWith(symbol_addr_ptr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
return true;
}
Added handling for external variables in function arguments to the expression parser. This means that structs can be returned from the "expr" command. llvm-svn: 115698
2010-10-06 06:26:43 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::MaybeHandleCallArguments (CallInst *Old)
Added handling for external variables in function arguments to the expression parser. This means that structs can be returned from the "expr" command. llvm-svn: 115698
2010-10-06 06:26:43 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
if (log)
log->Printf("MaybeHandleCallArguments(%s)", PrintValue(Old).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
for (unsigned op_index = 0, num_ops = Old->getNumArgOperands();
Added handling for external variables in function arguments to the expression parser. This means that structs can be returned from the "expr" command. llvm-svn: 115698
2010-10-06 06:26:43 +08:00
op_index < num_ops;
++op_index)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!MaybeHandleVariable(Old->getArgOperand(op_index))) // conservatively believe that this is a store
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't rewrite one of the arguments of a function call.\n");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added handling for external variables in function arguments to the expression parser. This means that structs can be returned from the "expr" command. llvm-svn: 115698
2010-10-06 06:26:43 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added handling for external variables in function arguments to the expression parser. This means that structs can be returned from the "expr" command. llvm-svn: 115698
2010-10-06 06:26:43 +08:00
return true;
}
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
bool
IRForTarget::HandleObjCClass(Value *classlist_reference)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
GlobalVariable *global_variable = dyn_cast<GlobalVariable>(classlist_reference);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (!global_variable)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
Constant *initializer = global_variable->getInitializer();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (!initializer)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (!initializer->hasName())
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
StringRef name(initializer->getName());
lldb_private::ConstString name_cstr(name.str().c_str());
Added the ability for clients to grab a set of symbol table indexes and then add them to a fast lookup map. lldb_private::Symtab now export the following public typedefs: namespace lldb_private { class Symtab { typedef std::vector<uint32_t> IndexCollection; typedef UniqueCStringMap<uint32_t> NameToIndexMap; }; } Clients can then find symbols by name and or type and end up with a Symtab::IndexCollection that is filled with indexes. These indexes can then be put into a name to index lookup map and control if the mangled and demangled names get added to the map: bool add_demangled = true; bool add_mangled = true; Symtab::NameToIndexMap name_to_index; symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index). This can be repeated as many times as needed to get a lookup table that you are happy with, and then this can be sorted: name_to_index.Sort(); Now name lookups can be done using a subset of the symbols you extracted from the symbol table. This is currently being used to extract objective C types from object files when there is no debug info in SymbolFileSymtab. Cleaned up how the objective C types were being vended to be more efficient and fixed some errors in the regular expression that was being used. llvm-svn: 145777
2011-12-04 04:02:42 +08:00
lldb::addr_t class_ptr = m_decl_map->GetSymbolAddress(name_cstr, lldb::eSymbolTypeObjCClass);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (log)
log->Printf("Found reference to Objective-C class %s (0x%llx)", name_cstr.AsCString(), (unsigned long long)class_ptr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (class_ptr == LLDB_INVALID_ADDRESS)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
if (global_variable->use_empty())
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
SmallVector<LoadInst *, 2> load_instructions;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
for (llvm::User *u : global_variable->users())
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
{
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
if (LoadInst *load_instruction = dyn_cast<LoadInst>(u))
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
load_instructions.push_back(load_instruction);
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
if (load_instructions.empty())
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *class_addr = ConstantInt::get(m_intptr_ty, (uint64_t)class_ptr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
for (LoadInst *load_instruction : load_instructions)
{
Constant *class_bitcast = ConstantExpr::getIntToPtr(class_addr, load_instruction->getType());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
load_instruction->replaceAllUsesWith(class_bitcast);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
If there are multiple uses of an Objective-C class symbol in the same expression, handle all of them instead of just the first one. <rdar://problem/13440133> llvm-svn: 177794
2013-03-23 09:01:16 +08:00
load_instruction->eraseFromParent();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
return true;
}
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
bool
IRForTarget::RemoveCXAAtExit (BasicBlock &basic_block)
{
BasicBlock::iterator ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
std::vector<CallInst *> calls_to_remove;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
for (ii = basic_block.begin();
ii != basic_block.end();
++ii)
{
Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
CallInst *call = dyn_cast<CallInst>(&inst);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
// MaybeHandleCallArguments handles error reporting; we are silent here
if (!call)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
bool remove = false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
llvm::Function *func = call->getCalledFunction();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
if (func && func->getName() == "__cxa_atexit")
remove = true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
llvm::Value *val = call->getCalledValue();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
if (val && val->getName() == "__cxa_atexit")
remove = true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
if (remove)
calls_to_remove.push_back(call);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
for (std::vector<CallInst *>::iterator ci = calls_to_remove.begin(), ce = calls_to_remove.end();
ci != ce;
++ci)
{
(*ci)->eraseFromParent();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
return true;
}
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::ResolveCalls(BasicBlock &basic_block)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
/////////////////////////////////////////////////////////////////////////
// Prepare the current basic block for execution in the remote process
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for calling functions from expressions. Right now we mock up the function as a variadic function when generating the IR for the call; we need to eventually make the function be the right type if the type is available. llvm-svn: 109543
2010-07-28 05:39:39 +08:00
BasicBlock::iterator ii;
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
for (ii = basic_block.begin();
ii != basic_block.end();
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
++ii)
{
Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
CallInst *call = dyn_cast<CallInst>(&inst);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// MaybeHandleCallArguments handles error reporting; we are silent here
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (call && !MaybeHandleCallArguments(call))
Fixed IRForTarget so that it errors out when function pointers are used. Previously, they caused a crash in the JIT because we didn't resolve them correctly. llvm-svn: 120728
2010-12-03 03:47:57 +08:00
return false;
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return true;
}
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::ResolveExternals (Function &llvm_function)
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
for (GlobalVariable &global_var : m_module->globals())
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
std::string global_name = global_var.getName().str();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf("Examining %s, DeclForGlobalValue returns %p",
Added checking to prevent a rare crash when getting the name for an external variable in the IR. llvm-svn: 147178
2011-12-23 05:24:49 +08:00
global_name.c_str(),
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
static_cast<void*>(DeclForGlobal(&global_var)));
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
if (global_name.find("OBJC_IVAR") == 0)
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (!HandleSymbol(&global_var))
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
Added checking to prevent a rare crash when getting the name for an external variable in the IR. llvm-svn: 147178
2011-12-23 05:24:49 +08:00
m_error_stream->Printf("Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol %s\n", global_name.c_str());
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
}
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
else if (global_name.find("OBJC_CLASSLIST_REFERENCES_$") != global_name.npos)
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (!HandleObjCClass(&global_var))
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Couldn't resolve the class for an Objective-C static method call\n");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Added functionality to call Objective-C class methods correctly, and added a testcase to check that it works. The main problem here is that Objective-C class method selectors are external references stored in a special data structure in the LLVM IR module for an expression. I just had to extract them and ensure that the real class object locations were properly resolved. llvm-svn: 143520
2011-11-02 07:38:03 +08:00
return false;
}
}
Fixed IRForTarget to handle Objective-C messages sent to "super". <rdar://problem/13042260> llvm-svn: 180217
2013-04-25 05:25:20 +08:00
else if (global_name.find("OBJC_CLASSLIST_SUP_REFS_$") != global_name.npos)
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (!HandleObjCClass(&global_var))
Fixed IRForTarget to handle Objective-C messages sent to "super". <rdar://problem/13042260> llvm-svn: 180217
2013-04-25 05:25:20 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Error [IRForTarget]: Couldn't resolve the class for an Objective-C static method call\n");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Fixed IRForTarget to handle Objective-C messages sent to "super". <rdar://problem/13042260> llvm-svn: 180217
2013-04-25 05:25:20 +08:00
return false;
}
}
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
else if (DeclForGlobal(&global_var))
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (!MaybeHandleVariable (&global_var))
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
Added checking to prevent a rare crash when getting the name for an external variable in the IR. llvm-svn: 147178
2011-12-23 05:24:49 +08:00
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't rewrite external variable %s\n", global_name.c_str());
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
Added support for the fragile ivars provided by Apple's Objective-C 2.0 runtime. They are enabled if the Objective-C runtime has the proper version. llvm-svn: 123694
2011-01-18 07:42:46 +08:00
}
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
return true;
}
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
bool
IRForTarget::ReplaceStrings ()
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
typedef std::map <GlobalVariable *, size_t> OffsetsTy;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
OffsetsTy offsets;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
for (GlobalVariable &gv : m_module->globals())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (!gv.hasInitializer())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
Constant *gc = gv.getInitializer();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
std::string str;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (gc->isNullValue())
{
Type *gc_type = gc->getType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
ArrayType *gc_array_type = dyn_cast<ArrayType>(gc_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (!gc_array_type)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
Type *gc_element_type = gc_array_type->getElementType();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
IntegerType *gc_integer_type = dyn_cast<IntegerType>(gc_element_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (gc_integer_type->getBitWidth() != 8)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
str = "";
}
else
{
Brought LLVM/Clang up to top of tree. The only change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
2012-02-09 11:22:41 +08:00
ConstantDataArray *gc_array = dyn_cast<ConstantDataArray>(gc);
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (!gc_array)
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (!gc_array->isCString())
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
if (log)
log->Printf("Found a GlobalVariable with string initializer %s", PrintValue(gc).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
str = gc_array->getAsString();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
offsets[&gv] = m_data_allocator.GetStream().GetSize();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator.GetStream().Write(str.c_str(), str.length() + 1);
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
Type *char_ptr_ty = Type::getInt8PtrTy(m_module->getContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
for (OffsetsTy::iterator oi = offsets.begin(), oe = offsets.end();
oi != oe;
++oi)
{
GlobalVariable *gv = oi->first;
size_t offset = oi->second;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
Constant *new_initializer = BuildRelocation(char_ptr_ty, offset);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (log)
log->Printf("Replacing GV %s with %s", PrintValue(gv).c_str(), PrintValue(new_initializer).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
for (llvm::User *u : gv->users())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
if (log)
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
log->Printf("Found use %s", PrintValue(u).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. (This part of the change was missed in r203463) Differential Revision: http://llvm-reviews.chandlerc.com/D3030 llvm-svn: 203475
2014-03-11 01:24:16 +08:00
ConstantExpr *const_expr = dyn_cast<ConstantExpr>(u);
StoreInst *store_inst = dyn_cast<StoreInst>(u);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (const_expr)
{
if (const_expr->getOpcode() != Instruction::GetElementPtr)
{
if (log)
log->Printf("Use (%s) of string variable is not a GetElementPtr constant", PrintValue(const_expr).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
Constant *bit_cast = ConstantExpr::getBitCast(new_initializer, const_expr->getOperand(0)->getType());
Constant *new_gep = const_expr->getWithOperandReplaced(0, bit_cast);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that prevented access to members of string literals ("hello"[2]). Also fixed a problem in which empty string literals were not being compiled correctly ((int)printf("") would print garbage). Added a testcase that covers both. llvm-svn: 137247
2011-08-11 05:05:52 +08:00
const_expr->replaceAllUsesWith(new_gep);
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
else if (store_inst)
{
Constant *bit_cast = ConstantExpr::getBitCast(new_initializer, store_inst->getValueOperand()->getType());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
store_inst->setOperand(0, bit_cast);
}
else
{
if (log)
log->Printf("Use (%s) of string variable is neither a constant nor a store", PrintValue(const_expr).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
gv->eraseFromParent();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return true;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::ReplaceStaticLiterals (llvm::BasicBlock &basic_block)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
typedef SmallVector <Value*, 2> ConstantList;
typedef SmallVector <llvm::Instruction*, 2> UserList;
typedef ConstantList::iterator ConstantIterator;
typedef UserList::iterator UserIterator;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
ConstantList static_constants;
UserList static_users;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
for (BasicBlock::iterator ii = basic_block.begin(), ie = basic_block.end();
ii != ie;
++ii)
{
llvm::Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
for (Value *operand_val : inst.operand_values())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
ConstantFP *operand_constant_fp = dyn_cast<ConstantFP>(operand_val);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made the IR interpreter move all floats, not just "wide" ones, to its own constant pool. This reflects the fact that the LLVM code generators for different targets move floats to their constant pools under varying conditions, and the JIT cannot (yet) be relied upon to relocate references to its constant pool correctly. llvm-svn: 155660
2012-04-27 04:51:20 +08:00
if (operand_constant_fp/* && operand_constant_fp->getType()->isX86_FP80Ty()*/)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
static_constants.push_back(operand_val);
static_users.push_back(ii);
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
ConstantIterator constant_iter;
UserIterator user_iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
for (constant_iter = static_constants.begin(), user_iter = static_users.begin();
constant_iter != static_constants.end();
++constant_iter, ++user_iter)
{
Value *operand_val = *constant_iter;
llvm::Instruction *inst = *user_iter;
ConstantFP *operand_constant_fp = dyn_cast<ConstantFP>(operand_val);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (operand_constant_fp)
{
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
Type *operand_type = operand_constant_fp->getType();
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
APFloat operand_apfloat = operand_constant_fp->getValueAPF();
APInt operand_apint = operand_apfloat.bitcastToAPInt();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
const uint8_t* operand_raw_data = (const uint8_t*)operand_apint.getRawData();
size_t operand_data_size = operand_apint.getBitWidth() / 8;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (log)
{
std::string s;
raw_string_ostream ss(s);
for (size_t index = 0;
index < operand_data_size;
++index)
{
ss << (uint32_t)operand_raw_data[index];
ss << " ";
}
ss.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
log->Printf("Found ConstantFP with size %" PRIu64 " and raw data %s", (uint64_t)operand_data_size, s.c_str());
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
lldb_private::DataBufferHeap data(operand_data_size, 0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
if (lldb::endian::InlHostByteOrder() != m_data_allocator.GetStream().GetByteOrder())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
uint8_t *data_bytes = data.GetBytes();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
for (size_t index = 0;
index < operand_data_size;
++index)
{
data_bytes[index] = operand_raw_data[operand_data_size - (1 + index)];
}
}
else
{
memcpy(data.GetBytes(), operand_raw_data, operand_data_size);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
uint64_t offset = m_data_allocator.GetStream().GetSize();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Minor fixes for ARM/iOS targets: - On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
2012-06-09 06:20:41 +08:00
size_t align = m_target_data->getPrefTypeAlignment(operand_type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Minor fixes for ARM/iOS targets: - On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
2012-06-09 06:20:41 +08:00
const size_t mask = (align - 1);
uint64_t aligned_offset = (offset + mask) & ~mask;
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator.GetStream().PutNHex8(aligned_offset - offset, 0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
m_data_allocator.GetStream().Write(data.GetBytes(), operand_data_size);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
llvm::Type *fp_ptr_ty = operand_constant_fp->getType()->getPointerTo();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +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
Constant *new_pointer = BuildRelocation(fp_ptr_ty, aligned_offset);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
llvm::LoadInst *fp_load = new llvm::LoadInst(new_pointer, "fp_load", inst);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
operand_constant_fp->replaceAllUsesWith(fp_load);
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return true;
}
Added support for calling functions from expressions. Right now we mock up the function as a variadic function when generating the IR for the call; we need to eventually make the function be the right type if the type is available. llvm-svn: 109543
2010-07-28 05:39:39 +08:00
static bool isGuardVariableRef(Value *V)
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
{
Audited the expression parser to find uninitialized pointers. Some of the spots are obviously initialized later, but it's better just to NULL the pointers out at initialization to make the code more robust when exposed to later changes. llvm-svn: 134670
2011-07-08 08:39:14 +08:00
Constant *Old = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!(Old = dyn_cast<Constant>(V)))
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Audited the expression parser to find uninitialized pointers. Some of the spots are obviously initialized later, but it's better just to NULL the pointers out at initialization to make the code more robust when exposed to later changes. llvm-svn: 134670
2011-07-08 08:39:14 +08:00
ConstantExpr *CE = NULL;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated to latest LLVM. Major LLVM changes: - Sema is now exported (and there was much rejoicing.) - Storage classes are now centrally defined. Also fixed some bugs that the new LLVM picked up. llvm-svn: 114622
2010-09-23 11:01:22 +08:00
if ((CE = dyn_cast<ConstantExpr>(V)))
{
if (CE->getOpcode() != Instruction::BitCast)
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Old = CE->getOperand(0);
Updated to latest LLVM. Major LLVM changes: - Sema is now exported (and there was much rejoicing.) - Storage classes are now centrally defined. Also fixed some bugs that the new LLVM picked up. llvm-svn: 114622
2010-09-23 11:01:22 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
GlobalVariable *GV = dyn_cast<GlobalVariable>(Old);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix issues with LLDB's interpreter and MS ABI guard variables. MS ABI guard variables end with @4IA, so this patch teaches the interpreter about that. Additionally, there was an issue with TurnGuardLoadIntoZero which was causing some guard uses of a variable to be missed. This fixes that by calling Instruction::replaceAllUsesWith() instead of trying to replicate that function. llvm-svn: 225547
2015-01-10 05:12:22 +08:00
if (!GV || !GV->hasName() ||
(!GV->getName().startswith("_ZGV") && // Itanium ABI guard variable
!GV->getName().endswith("@4IA"))) // Microsoft ABI guard variable
{
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
return false;
Fix issues with LLDB's interpreter and MS ABI guard variables. MS ABI guard variables end with @4IA, so this patch teaches the interpreter about that. Additionally, there was an issue with TurnGuardLoadIntoZero which was causing some guard uses of a variable to be missed. This fixes that by calling Instruction::replaceAllUsesWith() instead of trying to replicate that function. llvm-svn: 225547
2015-01-10 05:12:22 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
return true;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
void
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::TurnGuardLoadIntoZero(llvm::Instruction* guard_load)
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
{
Fix issues with LLDB's interpreter and MS ABI guard variables. MS ABI guard variables end with @4IA, so this patch teaches the interpreter about that. Additionally, there was an issue with TurnGuardLoadIntoZero which was causing some guard uses of a variable to be missed. This fixes that by calling Instruction::replaceAllUsesWith() instead of trying to replicate that function. llvm-svn: 225547
2015-01-10 05:12:22 +08:00
Constant *zero(Constant::getNullValue(guard_load->getType()));
guard_load->replaceAllUsesWith(zero);
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
guard_load->eraseFromParent();
}
static void ExciseGuardStore(Instruction* guard_store)
{
guard_store->eraseFromParent();
}
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::RemoveGuards(BasicBlock &basic_block)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
///////////////////////////////////////////////////////
// Eliminate any reference to guard variables found.
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for calling functions from expressions. Right now we mock up the function as a variadic function when generating the IR for the call; we need to eventually make the function be the right type if the type is available. llvm-svn: 109543
2010-07-28 05:39:39 +08:00
BasicBlock::iterator ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for calling functions from expressions. Right now we mock up the function as a variadic function when generating the IR for the call; we need to eventually make the function be the right type if the type is available. llvm-svn: 109543
2010-07-28 05:39:39 +08:00
typedef SmallVector <Instruction*, 2> InstrList;
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
typedef InstrList::iterator InstrIterator;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
InstrList guard_loads;
InstrList guard_stores;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
for (ii = basic_block.begin();
ii != basic_block.end();
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
++ii)
{
Instruction &inst = *ii;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
if (LoadInst *load = dyn_cast<LoadInst>(&inst))
if (isGuardVariableRef(load->getPointerOperand()))
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
guard_loads.push_back(&inst);
if (StoreInst *store = dyn_cast<StoreInst>(&inst))
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
if (isGuardVariableRef(store->getPointerOperand()))
guard_stores.push_back(&inst);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
InstrIterator iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
for (iter = guard_loads.begin();
iter != guard_loads.end();
++iter)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
TurnGuardLoadIntoZero(*iter);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
for (iter = guard_stores.begin();
iter != guard_stores.end();
++iter)
ExciseGuardStore(*iter);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated the IR converter for the target to eliminate spurious guard variables on expression statics. Updated the AST result synthesizer to eliminate the unneeded result pointer. Very rudimentary expressions now evaluate correctly in the target using the new JIT-based mechanism. llvm-svn: 109317
2010-07-24 09:37:44 +08:00
return true;
}
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// This function does not report errors; its callers are responsible.
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
bool
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
IRForTarget::UnfoldConstant(Constant *old_constant,
FunctionValueCache &value_maker,
FunctionValueCache &entry_instruction_finder)
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
SmallVector<User*, 16> users;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
// We do this because the use list might change, invalidating our iterator.
// Much better to keep a work list ourselves.
Update LLDB for LLVM iterator change in r203364 What was use_iterator is now user_iterator. Also switch to range-based APIs, as in Clang r203365. llvm-svn: 203463
2014-03-10 22:23:10 +08:00
for (llvm::User *u : old_constant->users())
users.push_back(u);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Patch by Matt Johnson to silence G++ warnings! Used hand merge to apply the diffs. I did not apply the diffs for FormatManager.h and the diffs for memberwise initialization for ValueObject.cpp because they changed since. I will ask my colleague to apply them later. llvm-svn: 135508
2011-07-20 03:48:13 +08:00
for (size_t i = 0;
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
i < users.size();
++i)
{
User *user = users[i];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
if (Constant *constant = dyn_cast<Constant>(user))
{
// synthesize a new non-constant equivalent of the constant
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
if (ConstantExpr *constant_expr = dyn_cast<ConstantExpr>(constant))
{
switch (constant_expr->getOpcode())
{
default:
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Unhandled constant expression type: \"%s\"", PrintValue(constant_expr).c_str());
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
return false;
case Instruction::BitCast:
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
FunctionValueCache bit_cast_maker ([&value_maker, &entry_instruction_finder, old_constant, constant_expr] (llvm::Function *function)->llvm::Value* {
// UnaryExpr
// OperandList[0] is value
if (constant_expr->getOperand(0) != old_constant)
return constant_expr;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return new BitCastInst(value_maker.GetValue(function),
constant_expr->getType(),
"",
llvm::cast<Instruction>(entry_instruction_finder.GetValue(function)));
});
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem in IRForTarget where we would not delete a constant after we replaced it with a dynamically-computed value. Also ensured that we replace all users of the constant if there are multiple ones. Added a testcase. <rdar://problem/14379043> llvm-svn: 186363
2013-07-16 07:31:47 +08:00
if (!UnfoldConstant(constant_expr, bit_cast_maker, entry_instruction_finder))
return false;
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
}
break;
case Instruction::GetElementPtr:
{
// GetElementPtrConstantExpr
// OperandList[0] is base
// OperandList[1]... are indices
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
FunctionValueCache get_element_pointer_maker ([&value_maker, &entry_instruction_finder, old_constant, constant_expr] (llvm::Function *function)->llvm::Value* {
Value *ptr = constant_expr->getOperand(0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (ptr == old_constant)
ptr = value_maker.GetValue(function);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
std::vector<Value*> index_vector;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
unsigned operand_index;
unsigned num_operands = constant_expr->getNumOperands();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (operand_index = 1;
operand_index < num_operands;
++operand_index)
{
Value *operand = constant_expr->getOperand(operand_index);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (operand == old_constant)
operand = value_maker.GetValue(function);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
index_vector.push_back(operand);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
ArrayRef <Value*> indices(index_vector);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added nullptr to fix build llvm-svn: 232345
2015-03-16 11:54:22 +08:00
return GetElementPtrInst::Create(nullptr, ptr, indices, "", llvm::cast<Instruction>(entry_instruction_finder.GetValue(function)));
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
});
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem in IRForTarget where we would not delete a constant after we replaced it with a dynamically-computed value. Also ensured that we replace all users of the constant if there are multiple ones. Added a testcase. <rdar://problem/14379043> llvm-svn: 186363
2013-07-16 07:31:47 +08:00
if (!UnfoldConstant(constant_expr, get_element_pointer_maker, entry_instruction_finder))
return false;
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
}
break;
}
}
else
{
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Unhandled constant type: \"%s\"", PrintValue(constant).c_str());
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
return false;
}
}
else
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (Instruction *inst = llvm::dyn_cast<Instruction>(user))
{
inst->replaceUsesOfWith(old_constant, value_maker.GetValue(inst->getParent()->getParent()));
}
else
{
if (log)
log->Printf("Unhandled non-constant type: \"%s\"", PrintValue(user).c_str());
return false;
}
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem in IRForTarget where we would not delete a constant after we replaced it with a dynamically-computed value. Also ensured that we replace all users of the constant if there are multiple ones. Added a testcase. <rdar://problem/14379043> llvm-svn: 186363
2013-07-16 07:31:47 +08:00
if (!isa<GlobalValue>(old_constant))
{
old_constant->destroyConstant();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixes to the IR generator in the expression parser to correctly unfold constant-folded global variables. Also added code to JIT the expression. Simple expressions are now JIT compiled successfully. llvm-svn: 108380
2010-07-15 07:40:29 +08:00
return true;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::ReplaceVariables (Function &llvm_function)
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
{
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
if (!m_resolve_vars)
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
m_decl_map->DoStructLayout();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
if (log)
log->Printf("Element arrangement:");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
uint32_t num_elements;
uint32_t element_index;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
size_t size;
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t alignment;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
if (!m_decl_map->GetStructInfo (num_elements, size, alignment))
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
Function::arg_iterator iter(llvm_function.getArgumentList().begin());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
if (iter == llvm_function.getArgumentList().end())
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes no arguments (should take at least a struct pointer)");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for calling functions from expressions. Right now we mock up the function as a variadic function when generating the IR for the call; we need to eventually make the function be the right type if the type is available. llvm-svn: 109543
2010-07-28 05:39:39 +08:00
Argument *argument = iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
if (argument->getName().equals("this"))
{
++iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
if (iter == llvm_function.getArgumentList().end())
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes only 'this' argument (should take a struct pointer too)");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
argument = iter;
}
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
else if (argument->getName().equals("self"))
{
++iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
if (iter == llvm_function.getArgumentList().end())
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes only 'self' argument (should take '_cmd' and a struct pointer too)");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
if (!iter->getName().equals("_cmd"))
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes '%s' after 'self' argument (should take '_cmd')", iter->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
++iter;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
if (iter == llvm_function.getArgumentList().end())
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes only 'self' and '_cmd' arguments (should take a struct pointer too)");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
argument = iter;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
if (!argument->getName().equals("$__lldb_arg"))
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Wrapper takes an argument named '%s' instead of the struct pointer", argument->getName().str().c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Arg: \"%s\"", PrintValue(argument).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
BasicBlock &entry_block(llvm_function.getEntryBlock());
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
Instruction *FirstEntryInstruction(entry_block.getFirstNonPHIOrDbg());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
if (!FirstEntryInstruction)
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't find the first instruction in the wrapper for use in rewriting");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
LLVMContext &context(m_module->getContext());
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
IntegerType *offset_type(Type::getInt32Ty(context));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
if (!offset_type)
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't produce an offset type");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
for (element_index = 0; element_index < num_elements; ++element_index)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
Audited the expression parser to find uninitialized pointers. Some of the spots are obviously initialized later, but it's better just to NULL the pointers out at initialization to make the code more robust when exposed to later changes. llvm-svn: 134670
2011-07-08 08:39:14 +08:00
const clang::NamedDecl *decl = NULL;
Value *value = NULL;
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t offset;
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
lldb_private::ConstString name;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a bug where the parser-specific members of persistent variables were staying around too long. This caused the following problem: - A persistent result variable is created for the result of an expression. The pointer to the corresponding Decl is stored in the variable. - The persistent variable is looked up during struct generation (correctly) using its Decl. - Another expression defines a new result variable which happens to have a Decl in the same place as the original result variable. - The persistent variable is looked up during struct generation using its Decl, but the old result variable appears first in the list and has the same Decl pointer. The fix is to destroy parser-specific data when it is no longer valid. Also improved some logging as I diagnosed the bug. llvm-svn: 112540
2010-08-31 06:17:16 +08:00
if (!m_decl_map->GetStructElement (decl, value, offset, name, element_index))
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
{
if (m_error_stream)
m_error_stream->Printf("Internal error [IRForTarget]: Structure information is incomplete");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
return false;
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
if (log)
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
log->Printf(" \"%s\" (\"%s\") placed at %" PRIu64,
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
name.GetCString(),
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
decl->getNameAsString().c_str(),
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
offset);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (value)
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
{
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (log)
log->Printf(" Replacing [%s]", PrintValue(value).c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
FunctionValueCache body_result_maker ([this, name, offset_type, offset, argument, value] (llvm::Function *function)->llvm::Value * {
// Per the comment at ASTResultSynthesizer::SynthesizeBodyResult, in cases where the result
// variable is an rvalue, we have to synthesize a dereference of the appropriate structure
// entry in order to produce the static variable that the AST thinks it is accessing.
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
llvm::Instruction *entry_instruction = llvm::cast<Instruction>(m_entry_instruction_finder.GetValue(function));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
ConstantInt *offset_int(ConstantInt::get(offset_type, offset, true));
Added nullptr to fix build llvm-svn: 232345
2015-03-16 11:54:22 +08:00
GetElementPtrInst *get_element_ptr = GetElementPtrInst::Create(nullptr,
argument,
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
offset_int,
"",
entry_instruction);
if (name == m_result_name && !m_result_is_pointer)
{
BitCastInst *bit_cast = new BitCastInst(get_element_ptr,
value->getType()->getPointerTo(),
"",
entry_instruction);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
LoadInst *load = new LoadInst(bit_cast, "", entry_instruction);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return load;
}
else
{
BitCastInst *bit_cast = new BitCastInst(get_element_ptr, value->getType(), "", entry_instruction);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return bit_cast;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
});
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (Constant *constant = dyn_cast<Constant>(value))
{
UnfoldConstant(constant, body_result_maker, m_entry_instruction_finder);
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
}
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
else if (Instruction *instruction = dyn_cast<Instruction>(value))
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
value->replaceAllUsesWith(body_result_maker.GetValue(instruction->getParent()->getParent()));
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
}
else
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
{
if (log)
log->Printf("Unhandled non-constant type: \"%s\"", PrintValue(value).c_str());
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Improved handling of static data in the expression parser. Now expression like the following work as expected: - (lldb) expr struct { int a; int b; } $blah = { 10, 20 } <no result> (lldb) expr $blah (<anonymous struct at Parse:6:5>) $blah = { (int) a = 10 (int) b = 20 } - Now the IRForTarget subsystem knows how to handle static initializers of various composite types. Also removed an unnecessary parameter from ClangExpressionDeclMap::GetFunctionInfo. llvm-svn: 142936
2011-10-26 02:36:40 +08:00
if (GlobalVariable *var = dyn_cast<GlobalVariable>(value))
var->eraseFromParent();
}
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
if (log)
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
log->Printf("Total structure [align %" PRId64 ", size %" PRIu64 "]", (int64_t)alignment, (uint64_t)size);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
return true;
}
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
llvm::Constant *
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
IRForTarget::BuildRelocation(llvm::Type *type, uint64_t offset)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
llvm::Constant *offset_int = ConstantInt::get(m_intptr_ty, offset);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
llvm::Constant *offset_array[1];
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
offset_array[0] = offset_int;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This change brings in the latest LLVM/Clang, and completes the support in the LLDB expression parser for incomplete types. Clang now imports types lazily, and we complete those types as necessary. Changes include: - ClangASTSource now supports three APIs which it passes to ClangExpressionDeclMap. CompleteType completes a TagDecl or an ObjCInterfaceDecl when needed; FindExternalVisibleDecls finds named entities that are visible in the expression's scope; and FindExternalLexicalDecls performs a (potentially restricted) search for entities inside a lexical scope like a namespace. These changes mean that entities in namespaces should work normally. - The SymbolFileDWARF code for searching a context for a specific name is now more general, and can search arbitrary contexts. - We are continuing to adapt our calls into LLVM from interfaces that take start and end iterators when accepting multiple items to interfaces that use ArrayRef. - I have cleaned up some code, especially our use of namespaces. This change is neutral for our testsuite and greatly improves correctness for large programs (like Clang) with complicated type systems. It should also lay the groundwork for improving the expression parser's performance as we are lazier and lazier about providing type information. llvm-svn: 136555
2011-07-30 10:42:06 +08:00
llvm::ArrayRef<llvm::Constant *> offsets(offset_array, 1);
Updated IRForTarget to change the way we generate relocations. We used to do GEP on a pointer to the result type, which is wrong. We should be doing GEP on a pointer to char, which allows us to offset correctly. This fixes the C modules testcase, so it's no longer ExpectFail. llvm-svn: 234918
2015-04-15 02:17:35 +08:00
llvm::Type *char_type = llvm::Type::getInt8Ty(m_module->getContext());
llvm::Type *char_pointer_type = char_type->getPointerTo();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated IRForTarget to change the way we generate relocations. We used to do GEP on a pointer to the result type, which is wrong. We should be doing GEP on a pointer to char, which allows us to offset correctly. This fixes the C modules testcase, so it's no longer ExpectFail. llvm-svn: 234918
2015-04-15 02:17:35 +08:00
llvm::Constant *reloc_placeholder_bitcast = ConstantExpr::getBitCast(m_reloc_placeholder, char_pointer_type);
llvm::Constant *reloc_getelementptr = ConstantExpr::getGetElementPtr(char_type, reloc_placeholder_bitcast, offsets);
Fixed a crash because we weren't generating type-safe relocations against @reloc_placeholder. <rdar://problem/20438754> llvm-svn: 234260
2015-04-07 07:51:08 +08:00
llvm::Constant *reloc_bitcast = ConstantExpr::getBitCast(reloc_getelementptr, type);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a crash because we weren't generating type-safe relocations against @reloc_placeholder. <rdar://problem/20438754> llvm-svn: 234260
2015-04-07 07:51:08 +08:00
return reloc_bitcast;
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
bool
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
IRForTarget::CompleteDataAllocation ()
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
if (!m_data_allocator.GetStream().GetSize())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
lldb::addr_t allocation = m_data_allocator.Allocate();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (log)
{
if (allocation)
log->Printf("Allocated static data at 0x%llx", (unsigned long long)allocation);
else
log->Printf("Failed to allocate static data");
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Refactored the expression parser so that the IR and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
2013-03-19 08:10:07 +08:00
if (!allocation || allocation == LLDB_INVALID_ADDRESS)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant *relocated_addr = ConstantInt::get(m_intptr_ty, (uint64_t)allocation);
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
Constant *relocated_bitcast = ConstantExpr::getIntToPtr(relocated_addr, llvm::Type::getInt8PtrTy(m_module->getContext()));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_reloc_placeholder->replaceAllUsesWith(relocated_bitcast);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_reloc_placeholder->eraseFromParent();
return true;
}
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
bool
IRForTarget::StripAllGVs (Module &llvm_module)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
std::vector<GlobalVariable *> global_vars;
std::set<GlobalVariable *>erased_vars;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
bool erased = true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
while (erased)
{
erased = false;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
for (GlobalVariable &global_var : llvm_module.globals())
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
global_var.removeDeadConstantUsers();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
if (global_var.use_empty())
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
{
if (log)
log->Printf("Did remove %s",
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
PrintValue(&global_var).c_str());
global_var.eraseFromParent();
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
erased = true;
break;
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
for (GlobalVariable &global_var : llvm_module.globals())
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
{
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
GlobalValue::user_iterator ui = global_var.user_begin();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Missing “if (log)” on a log printf. llvm-svn: 168602
2012-11-27 03:54:04 +08:00
if (log)
log->Printf("Couldn't remove %s because of %s",
Followed up on Ed Maste's patch with a few more User fixes. Also changed our iterations across global variables and instruction operands to reflect the new C++11 approach. llvm-svn: 203599
2014-03-12 03:19:16 +08:00
PrintValue(&global_var).c_str(),
Missing “if (log)” on a log printf. llvm-svn: 168602
2012-11-27 03:54:04 +08:00
PrintValue(*ui).c_str());
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
return true;
}
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
bool
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
IRForTarget::runOnModule (Module &llvm_module)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
lldb_private::Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_module = &llvm_module;
Move TargetData to DataLayout. llvm-svn: 165396
2012-10-09 00:28:57 +08:00
m_target_data.reset(new DataLayout(m_module));
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
m_intptr_ty = llvm::Type::getIntNTy(m_module->getContext(), m_target_data->getPointerSizeInBits());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (log)
{
std::string s;
raw_string_ostream oss(s);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
m_module->print(oss, NULL);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
oss.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
log->Printf("Module as passed in to IRForTarget: \n\"%s\"", s.c_str());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
Function* main_function = m_module->getFunction(StringRef(m_func_name.c_str()));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!main_function)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
if (log)
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Couldn't find \"%s()\" in the module", m_func_name.c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
if (m_error_stream)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_error_stream->Printf("Internal error [IRForTarget]: Couldn't find wrapper '%s' in the module", m_func_name.c_str());
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!FixFunctionLinkage (*main_function))
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
if (log)
log->Printf("Couldn't fix the linkage for the function");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
llvm::Type *int8_ty = Type::getInt8Ty(m_module->getContext());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
m_reloc_placeholder = new llvm::GlobalVariable((*m_module),
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
int8_ty,
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
false /* IsConstant */,
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
GlobalVariable::InternalLinkage,
Updated our IR processing to reflect best practices for making pointer-valued constants. llvm-svn: 197829
2013-12-21 03:55:02 +08:00
Constant::getNullValue(int8_ty),
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
"reloc_placeholder",
NULL /* InsertBefore */,
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
GlobalVariable::NotThreadLocal /* ThreadLocal */,
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
0 /* AddressSpace */);
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
////////////////////////////////////////////////////////////
Made many ConstString functions inlined in the header file. Changed all of our synthesized "___clang" functions, types and variables that get used in expressions over to have a prefix of "$_lldb". Now when we do name lookups we can easily switch off of the first '$' character to know if we should look through only our internal (when first char is '$') stuff, or when we should look through program variables, functions and types. Converted all of the clang expression code over to using "const ConstString&" values for names instead of "const char *" since there were many places that were converting the "const char *" names into ConstString names and them throwing them away. We now avoid making a lot of ConstString conversions and benefit from the quick comparisons in a few extra spots. Converted a lot of code from LLVM coding conventions into LLDB coding conventions. llvm-svn: 116634
2010-10-16 06:48:33 +08:00
// Replace $__lldb_expr_result with a persistent variable
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!CreateResultVariable(*main_function))
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
{
if (log)
log->Printf("CreateResultVariable() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// CreateResultVariable() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added automatically generated result variables for each expression. It is now possible to do things like this: (lldb) expr int $i = 5; $i + 1 $0 = (int) 6 (lldb) expr $i + 3 $1 = (int) 8 (lldb) expr $1 + $0 $2 = (int) 14 As a bonus, this allowed us to move printing of expression results into the ClangPersistentVariable class. This code needs a bit of refactoring -- in particular, ClangExpressionDeclMap has eaten one too many bacteria and needs to undergo mitosis -- but the infrastructure appears to be holding up nicely. llvm-svn: 110896
2010-08-12 09:56:52 +08:00
return false;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
}
Added a fix that allows newly-constructed objects to returned by expressions, by removing the __cxa_atexit call that would normally cause these objects to be destroyed. This also prevents many errors of the form Couldn't rewrite one of the arguments of a function call error: Couldn't materialize struct: Structure hasn't been laid out yet <rdar://problem/11309402> llvm-svn: 160596
2012-07-21 10:02:15 +08:00
Minor logging changes: added logging right before the expression makes it to the JIT, and made some logging only appear in verbose mode. llvm-svn: 143467
2011-11-02 01:33:54 +08:00
if (log && log->GetVerbose())
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
std::string s;
raw_string_ostream oss(s);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_module->print(oss, NULL);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
oss.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
log->Printf("Module after creating the result variable: \n\"%s\"", s.c_str());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (Module::iterator fi = m_module->begin(), fe = m_module->end();
fi != fe;
++fi)
{
llvm::Function *function = fi;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (function->begin() == function->end())
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
Function::iterator bbi;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (bbi = function->begin();
bbi != function->end();
++bbi)
{
if (!RemoveGuards(*bbi))
{
if (log)
log->Printf("RemoveGuards() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
// RemoveGuards() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!RewritePersistentAllocs(*bbi))
{
if (log)
log->Printf("RewritePersistentAllocs() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
// RewritePersistentAllocs() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!RemoveCXAAtExit(*bbi))
{
if (log)
log->Printf("RemoveCXAAtExit() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
// RemoveCXAAtExit() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
///////////////////////////////////////////////////////////////////////////////
// Fix all Objective-C constant strings to use NSStringWithCString:encoding:
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!RewriteObjCConstStrings())
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
{
if (log)
log->Printf("RewriteObjCConstStrings() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// RewriteObjCConstStrings() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added support for constant strings of the form @"this-is-a-string". They are replaced with calls to the CoreFoundation function CFStringCreateWithBytes() by a portion of the IRForTarget pass. llvm-svn: 119582
2010-11-18 07:00:36 +08:00
return false;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
///////////////////////////////
// Resolve function pointers
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!ResolveFunctionPointers(llvm_module))
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
{
if (log)
log->Printf("ResolveFunctionPointers() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
// ResolveFunctionPointers() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem that caused LLDB to fail to execute expressions that used function pointers. The problem was that IRForTarget previously only scanned the IR for the expression for call instructions; if a function was used in another context, it was ignored. Now LLDB scans the Module for functions that are only declared (not also defined -- so these are externals); it then constructs function pointers for these functions and substitutes them wherever the function is used. Also made some changes so that "expr main" works just as well as "expr &main"; they end up being the same code, but LLDB was generating the result variable in different ways. llvm-svn: 136928
2011-08-05 05:37:47 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (Module::iterator fi = m_module->begin(), fe = m_module->end();
fi != fe;
++fi)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
llvm::Function *function = fi;
for (llvm::Function::iterator bbi = function->begin(), bbe = function->end();
bbi != bbe;
++bbi)
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!RewriteObjCSelectors(*bbi))
{
if (log)
log->Printf("RewriteObjCSelectors() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
// RewriteObjCSelectors() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
}
Changed the IRForTarget pass to ensure that all sel_getName() calls are generated for all Objective-C selectors before static literals are moved to the static allocation. This prevents errors of the form Internal error [IRForTarget]: Couldn't change a static reference to an Objective-C selector to a dynamic reference <rdar://problem/11331906> llvm-svn: 160887
2012-07-28 03:25:24 +08:00
}
Added support for persistent variables to the expression parser. It is now possible to type: (lldb) expr int $i = 5; $i + 1 (int) 6 (lldb) expr $i + 2 (int) 7 The skeleton for automatic result variables is also implemented. The changes affect: - the process, which now contains a ClangPersistentVariables object that holds persistent variables associated with it - the expression parser, which now uses the persistent variables during variable lookup - TaggedASTType, where I loaded some commonly used tags into a header so that they are interchangeable between different clients of the class llvm-svn: 110777
2010-08-11 11:57:18 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (Module::iterator fi = m_module->begin(), fe = m_module->end();
fi != fe;
++fi)
Changed the IRForTarget pass to ensure that all sel_getName() calls are generated for all Objective-C selectors before static literals are moved to the static allocation. This prevents errors of the form Internal error [IRForTarget]: Couldn't change a static reference to an Objective-C selector to a dynamic reference <rdar://problem/11331906> llvm-svn: 160887
2012-07-28 03:25:24 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
llvm::Function *function = fi;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
for (llvm::Function::iterator bbi = function->begin(), bbe = function->end();
bbi != bbe;
++bbi)
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
{
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!ResolveCalls(*bbi))
{
if (log)
log->Printf("ResolveCalls() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
// ResolveCalls() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!ReplaceStaticLiterals(*bbi))
{
if (log)
log->Printf("ReplaceStaticLiterals() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
return false;
}
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
}
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
////////////////////////////////////////////////////////////////////////
// Run function-level passes that only make sense on the main function
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!ResolveExternals(*main_function))
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
{
if (log)
log->Printf("ResolveExternals() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// ResolveExternals() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Made variable resolution more robust by handling every external variable reference in the module, and returning a clean error (instead of letting LLVM issue a fatal error) if the variable could not be resolved. llvm-svn: 118388
2010-11-08 08:31:32 +08:00
return false;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Hitherto the IRForTarget infrastructure has mainly been suitable for preparing a single IR function for operation in the target. However, using blocks and lambdas creates other IR functions that also need to be processed. I have audited IRForTarget to make it process multiple functions. Where IRForTarget would add new instructions at the beginning of the main expression function, it now adds them on-demand in the function where they are needed. This is enabled by a system of FunctionValueCaches, which invoke a lambda to create or derive the values as needed, or report the result of that lambda if it has already been called for the given function. <rdar://problem/14180236> llvm-svn: 185224
2013-06-29 05:44:15 +08:00
if (!ReplaceVariables(*main_function))
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
{
if (log)
log->Printf("ReplaceVariables() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added error reporting to IRForTarget so that the user doesn't have to enable logging to see where something went wrong. llvm-svn: 124342
2011-01-27 09:07:04 +08:00
// ReplaceVariables() reports its own errors, so we don't do so here
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Switched the expression parser from using TargetData to using Clang to get type sizes. This fixes a bug where the type size for a double[2] was being wrongly reported as 8 instead of 16 bytes, causing problems for IRForTarget. Also improved logging so that the next bug in this area will be easier to find. llvm-svn: 115208
2010-10-01 05:18:25 +08:00
return false;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!ReplaceStrings())
{
if (log)
log->Printf("ReplaceStrings() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
if (!CompleteDataAllocation())
{
if (log)
log->Printf("CompleteDataAllocation() failed");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Brought LLDB top-of-tree into sync with LLVM/Clang top-of-tree. Removed all local patches and llvm.zip. The intent is that fron now on top-of-tree will always build against LLVM/Clang top-of-tree, and that problems building will be resolved as they occur. Stable release branches of LLDB can be constructed as needed and linked to specific release branches of LLVM/Clang. llvm-svn: 164563
2012-09-25 06:25:51 +08:00
if (!StripAllGVs(llvm_module))
{
if (log)
log->Printf("StripAllGVs() failed");
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Minor logging changes: added logging right before the expression makes it to the JIT, and made some logging only appear in verbose mode. llvm-svn: 143467
2011-11-02 01:33:54 +08:00
if (log && log->GetVerbose())
"expr -i" now performs the required transforms to prepare the IR for JIT compilation. We still need to do the JIT compilation and move the arguments in/out of target memory. llvm-svn: 108279
2010-07-14 05:41:46 +08:00
{
Added and improved logging. This is helping us as we diagnose a problem where we're not correctly emitting PIC code. llvm-svn: 109568
2010-07-28 09:00:59 +08:00
std::string s;
raw_string_ostream oss(s);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-24 05:40:23 +08:00
m_module->print(oss, NULL);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added and improved logging. This is helping us as we diagnose a problem where we're not correctly emitting PIC code. llvm-svn: 109568
2010-07-28 09:00:59 +08:00
oss.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Added quotes around names that are being lookup up or inspected in the expression logging. Added some properties to the "objc" test. The expression parser can currently display properties that are backed by the default functions "expr myStr.string" will work. But it won't currently work when the property is backed by a different function such as "expr myStr.date". llvm-svn: 119103
2010-11-15 09:47:11 +08:00
log->Printf("Module after preparing for execution: \n\"%s\"", s.c_str());
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
return true;
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
}
void
Added some logging back and cleaned up the code to match LLDB's coding conventions. llvm-svn: 119771
2010-11-19 09:05:25 +08:00
IRForTarget::assignPassManager (PMStack &pass_mgr_stack, PassManagerType pass_mgr_type)
Added the skeleton of an IR transformer that will prepare IR for execution in the target. Wired the expression command to use this IR transformer when conversion to DWARF fails, and wired conversion to DWARF to always fail (well, we don't generate any DWARF...) llvm-svn: 107559
2010-07-03 09:35:46 +08:00
{
}
PassManagerType
IRForTarget::getPotentialPassManagerType() const
{
return PMT_ModulePassManager;
}