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

1389 lines
46 KiB
C++
Raw Normal View History

Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
//===-- IRExecutionUnit.cpp -------------------------------------*- C++ -*-===//
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
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/ExecutionEngine/ExecutionEngine.h"
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
#include "llvm/IR/Constants.h"
Fixed a problem where inline assembly errors caused LLDB to crash. <rdar://problem/13497915> llvm-svn: 178115
2013-03-27 11:09:55 +08:00
#include "llvm/IR/LLVMContext.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 "llvm/IR/Module.h"
Fixed a problem where inline assembly errors caused LLDB to crash. <rdar://problem/13497915> llvm-svn: 178115
2013-03-27 11:09:55 +08:00
#include "llvm/Support/SourceMgr.h"
Don't #include FormatManager.h from Debugger.h Debugger.h is a huge file that gets included everywhere, and FormatManager.h brings in a ton of unnecessary stuff and doesn't even use anything from it in the header. llvm-svn: 231161
2015-03-04 07:11:11 +08:00
#include "llvm/Support/raw_ostream.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/DataBufferHeap.h"
#include "lldb/Core/DataExtractor.h"
Add a new disassembly-format specification so that the disassembler output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
2014-10-11 07:07:36 +08:00
#include "lldb/Core/Debugger.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/Disassembler.h"
#include "lldb/Core/Log.h"
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
#include "lldb/Core/Module.h"
#include "lldb/Core/Section.h"
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
#include "lldb/Symbol/CompileUnit.h"
Don't #include FormatManager.h from Debugger.h Debugger.h is a huge file that gets included everywhere, and FormatManager.h brings in a ton of unnecessary stuff and doesn't even use anything from it in the header. llvm-svn: 231161
2015-03-04 07:11:11 +08:00
#include "lldb/Symbol/SymbolContext.h"
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
#include "lldb/Symbol/SymbolVendor.h"
#include "lldb/Symbol/SymbolFile.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"
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/Target.h"
Don't #include FormatManager.h from Debugger.h Debugger.h is a huge file that gets included everywhere, and FormatManager.h brings in a ton of unnecessary stuff and doesn't even use anything from it in the header. llvm-svn: 231161
2015-03-04 07:11:11 +08:00
#include "lldb/Target/ObjCLanguageRuntime.h"
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
#include "lldb/Utility/LLDBAssert.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
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
#include "lldb/../../source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.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
using namespace lldb_private;
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. llvm-svn: 179805
2013-04-19 06:45:39 +08:00
IRExecutionUnit::IRExecutionUnit (std::unique_ptr<llvm::LLVMContext> &context_ap,
std::unique_ptr<llvm::Module> &module_ap,
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
ConstString &name,
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
const lldb::TargetSP &target_sp,
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
const SymbolContext &sym_ctx,
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
std::vector<std::string> &cpu_features) :
Audited the existing Materializer code to ensure that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
2013-04-16 01:12:47 +08:00
IRMemoryMap(target_sp),
Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
2013-04-19 02:10:51 +08:00
m_context_ap(context_ap.release()),
m_module_ap(module_ap.release()),
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_module(m_module_ap.get()),
Updated the IRExecutionUnit to keep local copies of the data it writes down into the process even if the process doesn't exist. This will allow the IR interpreter to access static data allocated on the expression's behalf. Also cleaned up object ownership in the IRExecutionUnit so that allocations are created into the allocations vector. This avoids needless data copies. <rdar://problem/13424594> llvm-svn: 177456
2013-03-20 07:03:21 +08:00
m_cpu_features(cpu_features),
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_name(name),
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
m_sym_ctx(sym_ctx),
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_did_jit(false),
m_function_load_addr(LLDB_INVALID_ADDRESS),
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
m_function_end_load_addr(LLDB_INVALID_ADDRESS),
m_reported_allocations(false)
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
IRExecutionUnit::WriteNow (const uint8_t *bytes,
size_t size,
Error &error)
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
{
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
const bool zero_memory = false;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
lldb::addr_t allocation_process_addr = Malloc (size,
8,
lldb::ePermissionsWritable | lldb::ePermissionsReadable,
eAllocationPolicyMirror,
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
zero_memory,
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
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
return LLDB_INVALID_ADDRESS;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
WriteMemory(allocation_process_addr, bytes, size, error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!error.Success())
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Error err;
Free (allocation_process_addr, 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
return LLDB_INVALID_ADDRESS;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (Log *log = lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS))
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
DataBufferHeap my_buffer(size, 0);
Error err;
ReadMemory(my_buffer.GetBytes(), allocation_process_addr, size, err);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (err.Success())
{
DataExtractor my_extractor(my_buffer.GetBytes(), my_buffer.GetByteSize(), lldb::eByteOrderBig, 8);
Better logging for the IRExecutionUnit so that we can see exactly what data was put where. llvm-svn: 199701
2014-01-21 08:54:48 +08:00
my_extractor.PutToLog(log, 0, my_buffer.GetByteSize(), allocation_process_addr, 16, DataExtractor::TypeUInt8);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return allocation_process_addr;
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
}
void
IRExecutionUnit::FreeNow (lldb::addr_t allocation)
{
if (allocation == LLDB_INVALID_ADDRESS)
return;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Error err;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Free(allocation, err);
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
}
Error
IRExecutionUnit::DisassembleFunction (Stream &stream,
lldb::ProcessSP &process_wp)
{
<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
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
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
ExecutionContext exe_ctx(process_wp);
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
Error ret;
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
ret.Clear();
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 func_local_addr = LLDB_INVALID_ADDRESS;
lldb::addr_t func_remote_addr = 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
for (JittedFunction &function : m_jitted_functions)
{
Fix function name lookup in IRExecutionEngine.cpp. Summary: Without this commit, when `log enable lldb expr` is enabled, the disassembly of JIT'ed code is never displayed. Reviewers: spyffe, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20312 llvm-svn: 271863
2016-06-06 10:50:46 +08:00
if (function.m_name == m_name)
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
{
func_local_addr = function.m_local_addr;
func_remote_addr = function.m_remote_addr;
}
}
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 (func_local_addr == LLDB_INVALID_ADDRESS)
{
ret.SetErrorToGenericError();
ret.SetErrorStringWithFormat("Couldn't find function %s for disassembly", m_name.AsCString());
return ret;
}
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 (log)
log->Printf("Found function, has local address 0x%" PRIx64 " and remote address 0x%" PRIx64, (uint64_t)func_local_addr, (uint64_t)func_remote_addr);
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
std::pair <lldb::addr_t, lldb::addr_t> func_range;
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
func_range = GetRemoteRangeForLocal(func_local_addr);
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 (func_range.first == 0 && func_range.second == 0)
{
ret.SetErrorToGenericError();
ret.SetErrorStringWithFormat("Couldn't find code range for function %s", m_name.AsCString());
return ret;
}
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 (log)
log->Printf("Function's code range is [0x%" PRIx64 "+0x%" PRIx64 "]", func_range.first, func_range.second);
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
Target *target = exe_ctx.GetTargetPtr();
if (!target)
{
ret.SetErrorToGenericError();
ret.SetErrorString("Couldn't find the target");
return ret;
}
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::DataBufferSP buffer_sp(new DataBufferHeap(func_range.second, 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
Process *process = exe_ctx.GetProcessPtr();
Error err;
process->ReadMemory(func_remote_addr, buffer_sp->GetBytes(), buffer_sp->GetByteSize(), 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 (!err.Success())
{
ret.SetErrorToGenericError();
ret.SetErrorStringWithFormat("Couldn't read from process: %s", err.AsCString("unknown error"));
return ret;
}
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
ArchSpec arch(target->GetArchitecture());
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
const char *plugin_name = NULL;
const char *flavor_string = NULL;
The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
2013-07-31 10:19:15 +08:00
lldb::DisassemblerSP disassembler_sp = Disassembler::FindPlugin(arch, flavor_string, plugin_name);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
2013-07-31 10:19:15 +08:00
if (!disassembler_sp)
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
{
ret.SetErrorToGenericError();
ret.SetErrorStringWithFormat("Unable to find disassembler plug-in for %s architecture.", arch.GetArchitectureName());
return ret;
}
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 (!process)
{
ret.SetErrorToGenericError();
ret.SetErrorString("Couldn't find the process");
return ret;
}
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
DataExtractor extractor(buffer_sp,
process->GetByteOrder(),
target->GetArchitecture().GetAddressByteSize());
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 (log)
{
log->Printf("Function data has contents:");
<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
extractor.PutToLog (log,
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
0,
extractor.GetByteSize(),
func_remote_addr,
16,
DataExtractor::TypeUInt8);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
2013-07-31 10:19:15 +08:00
disassembler_sp->DecodeInstructions (Address (func_remote_addr), extractor, 0, UINT32_MAX, false, false);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
2013-07-31 10:19:15 +08:00
InstructionList &instruction_list = disassembler_sp->GetInstructionList();
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
instruction_list.Dump(&stream, true, true, &exe_ctx);
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
return ret;
}
Fixed a problem where inline assembly errors caused LLDB to crash. <rdar://problem/13497915> llvm-svn: 178115
2013-03-27 11:09:55 +08:00
static void ReportInlineAsmError(const llvm::SMDiagnostic &diagnostic, void *Context, unsigned LocCookie)
{
Error *err = static_cast<Error*>(Context);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a problem where inline assembly errors caused LLDB to crash. <rdar://problem/13497915> llvm-svn: 178115
2013-03-27 11:09:55 +08:00
if (err && err->Success())
{
err->SetErrorToGenericError();
err->SetErrorStringWithFormat("Inline assembly error: %s", diagnostic.getMessage().str().c_str());
}
}
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
void
IRExecutionUnit::ReportSymbolLookupError(const ConstString &name)
{
m_failed_lookups.push_back(name);
}
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
void
IRExecutionUnit::GetRunnableInfo(Error &error,
lldb::addr_t &func_addr,
lldb::addr_t &func_end)
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
lldb::ProcessSP process_sp(GetProcessWP().lock());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
static std::recursive_mutex s_runnable_info_mutex;
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
func_addr = LLDB_INVALID_ADDRESS;
func_end = 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
if (!process_sp)
{
error.SetErrorToGenericError();
error.SetErrorString("Couldn't write the JIT compiled code into the process because the process is invalid");
return;
}
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_did_jit)
{
func_addr = m_function_load_addr;
func_end = m_function_end_load_addr;
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
return;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
};
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
std::lock_guard<std::recursive_mutex> guard(s_runnable_info_mutex);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_did_jit = true;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
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
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
std::string error_string;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (log)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
std::string s;
llvm::raw_string_ostream oss(s);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_module->print(oss, NULL);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
oss.flush();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
log->Printf ("Module being sent to JIT: \n%s", s.c_str());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
llvm::Triple triple(m_module->getTargetTriple());
llvm::Reloc::Model relocModel;
llvm::CodeModel::Model codeModel;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (triple.isOSBinFormatELF())
{
relocModel = llvm::Reloc::Static;
}
else
{
relocModel = llvm::Reloc::PIC_;
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
// This will be small for 32-bit and large for 64-bit.
codeModel = llvm::CodeModel::JITDefault;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_module_ap->getContext().setInlineAsmDiagnosticHandler(ReportInlineAsmError, &error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Update for llvm api change. llvm-svn: 215969
2014-08-19 12:27:03 +08:00
llvm::EngineBuilder builder(std::move(m_module_ap));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
builder.setEngineKind(llvm::EngineKind::JIT)
.setErrorStr(&error_string)
.setRelocationModel(relocModel)
Revert "Fix a build breakage. Looks like the LLVM side of this change has been reverted" This reverts commit r223375. We need to use unique_ptr to build with LLVM r223183. llvm-svn: 223388
2014-12-05 05:26:25 +08:00
.setMCJITMemoryManager(std::unique_ptr<MemoryManager>(new MemoryManager(*this)))
Clean-up warnings on Linux/GCC llvm-svn: 217862
2014-09-16 14:34:29 +08:00
.setCodeModel(codeModel)
Really fix the LLDB build llvm-svn: 217003
2014-09-03 08:40:36 +08:00
.setOptLevel(llvm::CodeGenOpt::Less);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
llvm::StringRef mArch;
llvm::StringRef mCPU;
llvm::SmallVector<std::string, 0> mAttrs;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (std::string &feature : m_cpu_features)
mAttrs.push_back(feature);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
llvm::TargetMachine *target_machine = builder.selectTarget(triple,
mArch,
mCPU,
mAttrs);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_execution_engine_ap.reset(builder.create(target_machine));
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
m_strip_underscore = (m_execution_engine_ap->getDataLayout().getGlobalPrefix() == '_');
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!m_execution_engine_ap.get())
{
error.SetErrorToGenericError();
error.SetErrorStringWithFormat("Couldn't JIT the function: %s", error_string.c_str());
return;
}
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
// Make sure we see all sections, including ones that don't have relocations...
m_execution_engine_ap->setProcessAllSections(true);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_execution_engine_ap->DisableLazyCompilation();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
for (llvm::Function &function : *m_module)
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
{
Don't register the addresses of private symbols from expressions. They're not supposed to go in the symbol table, and in fact the way the JIT is currently implemented it sometimes crashes when you try to get the address of such a function. So we skip them. llvm-svn: 264821
2016-03-30 11:44:51 +08:00
if (function.isDeclaration() || function.hasPrivateLinkage())
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
continue;
const bool external = function.hasExternalLinkage() || function.hasLinkOnceODRLinkage();
void *fun_ptr = m_execution_engine_ap->getPointerToFunction(&function);
if (!error.Success())
{
// We got an error through our callback!
return;
}
if (!fun_ptr)
{
error.SetErrorToGenericError();
error.SetErrorStringWithFormat("'%s' was in the JITted module but wasn't lowered", function.getName().str().c_str());
return;
}
m_jitted_functions.push_back (JittedFunction(function.getName().str().c_str(), external, (lldb::addr_t)fun_ptr));
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
CommitAllocations(process_sp);
ReportAllocations(*m_execution_engine_ap);
// We have to do this after calling ReportAllocations because for the MCJIT, getGlobalValueAddress
// will cause the JIT to perform all relocations. That can only be done once, and has to happen
// after we do the remapping from local -> remote.
// That means we don't know the local address of the Variables, but we don't need that for anything,
// so that's okay.
std::function<void (llvm::GlobalValue &)> RegisterOneValue = [this] (llvm::GlobalValue &val) {
if (val.hasExternalLinkage() && !val.isDeclaration())
{
uint64_t var_ptr_addr = m_execution_engine_ap->getGlobalValueAddress(val.getName().str());
lldb::addr_t remote_addr = GetRemoteAddressForLocal(var_ptr_addr);
// This is a really unfortunae API that sometimes returns local addresses and sometimes returns remote addresses, based on whether
// the variable was relocated during ReportAllocations or not.
if (remote_addr == LLDB_INVALID_ADDRESS)
{
remote_addr = var_ptr_addr;
}
if (var_ptr_addr != 0)
m_jitted_global_variables.push_back (JittedGlobalVariable (val.getName().str().c_str(), LLDB_INVALID_ADDRESS, remote_addr));
}
};
for (llvm::GlobalVariable &global_var : m_module->getGlobalList())
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
{
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
RegisterOneValue(global_var);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
for (llvm::GlobalAlias &global_alias : m_module->getAliasList())
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
{
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
RegisterOneValue(global_alias);
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
WriteData(process_sp);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
if (m_failed_lookups.size())
{
StreamString ss;
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
ss.PutCString("Couldn't lookup symbols:\n");
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
bool emitNewLine = false;
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
for (const ConstString &failed_lookup : m_failed_lookups)
{
if (emitNewLine)
ss.PutCString("\n");
emitNewLine = true;
ss.PutCString(" ");
Make many mangled functions that might demangle a name be allowed to specify a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
2015-07-09 06:32:23 +08:00
ss.PutCString(Mangled(failed_lookup).GetDemangledName(lldb::eLanguageTypeObjC_plus_plus).AsCString());
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
m_failed_lookups.clear();
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
error.SetErrorString(ss.GetData());
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
return;
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
m_function_load_addr = LLDB_INVALID_ADDRESS;
m_function_end_load_addr = LLDB_INVALID_ADDRESS;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (JittedFunction &jitted_function : m_jitted_functions)
{
jitted_function.m_remote_addr = GetRemoteAddressForLocal (jitted_function.m_local_addr);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
if (!m_name.IsEmpty() && jitted_function.m_name == m_name)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
AddrRange func_range = GetRemoteRangeForLocal(jitted_function.m_local_addr);
m_function_end_load_addr = func_range.first + func_range.second;
m_function_load_addr = jitted_function.m_remote_addr;
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
}
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (log)
{
log->Printf("Code can be run in the target.");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
StreamString disassembly_stream;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Error err = DisassembleFunction(disassembly_stream, process_sp);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (!err.Success())
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
log->Printf("Couldn't disassemble function : %s", err.AsCString("unknown error"));
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
}
else
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
log->Printf("Function disassembly:\n%s", disassembly_stream.GetData());
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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Better logging for the IRExecutionUnit so that we can see exactly what data was put where. llvm-svn: 199701
2014-01-21 08:54:48 +08:00
log->Printf("Sections: ");
for (AllocationRecord &record : m_records)
{
if (record.m_process_address != LLDB_INVALID_ADDRESS)
{
record.dump(log);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Better logging for the IRExecutionUnit so that we can see exactly what data was put where. llvm-svn: 199701
2014-01-21 08:54:48 +08:00
DataBufferHeap my_buffer(record.m_size, 0);
Error err;
ReadMemory(my_buffer.GetBytes(), record.m_process_address, record.m_size, err);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Better logging for the IRExecutionUnit so that we can see exactly what data was put where. llvm-svn: 199701
2014-01-21 08:54:48 +08:00
if (err.Success())
{
DataExtractor my_extractor(my_buffer.GetBytes(), my_buffer.GetByteSize(), lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, my_buffer.GetByteSize(), record.m_process_address, 16, DataExtractor::TypeUInt8);
}
}
Log information about sections that didn't make it into the target's memory. llvm-svn: 251084
2015-10-23 08:39:09 +08:00
else
{
record.dump(log);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Log information about sections that didn't make it into the target's memory. llvm-svn: 251084
2015-10-23 08:39:09 +08:00
DataExtractor my_extractor ((const void*)record.m_host_address, record.m_size, lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, record.m_size, record.m_host_address, 16, DataExtractor::TypeUInt8);
}
Better logging for the IRExecutionUnit so that we can see exactly what data was put where. llvm-svn: 199701
2014-01-21 08:54:48 +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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
func_addr = m_function_load_addr;
func_end = m_function_end_load_addr;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return;
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
}
IRExecutionUnit::~IRExecutionUnit ()
{
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-17 07:25:35 +08:00
m_module_ap.reset();
m_execution_engine_ap.reset();
m_context_ap.reset();
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
}
IRExecutionUnit::MemoryManager::MemoryManager (IRExecutionUnit &parent) :
Adjust to LLVM JIT API change Those wrapper functions seems not used by lldb... Removed Reference for replacing JITMemoryManager with SectionMemoryManager replacing "llvm::JITMemoryManager::CreateDefaultMemManager()" with "new llvm::SectionMemoryManager()" http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-jitlistener/llvm-jitlistener.cpp?r1=218316&r2=218315&pathrev=218316 Change by Tong Shen. Tested: Ubuntu 14.04 x86_64 MacOSX 10.9.5 with Xcode Version 6.1 (6A1030) (Beta) llvm-svn: 218383
2014-09-24 23:55:47 +08:00
m_default_mm_ap (new llvm::SectionMemoryManager()),
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_parent (parent)
{
}
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
IRExecutionUnit::MemoryManager::~MemoryManager ()
{
}
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
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
lldb::SectionType
IRExecutionUnit::GetSectionTypeFromSectionName (const llvm::StringRef &name, IRExecutionUnit::AllocationKind alloc_kind)
{
lldb::SectionType sect_type = lldb::eSectionTypeCode;
switch (alloc_kind)
{
case AllocationKind::Stub: sect_type = lldb::eSectionTypeCode; break;
case AllocationKind::Code: sect_type = lldb::eSectionTypeCode; break;
case AllocationKind::Data: sect_type = lldb::eSectionTypeData; break;
case AllocationKind::Global:sect_type = lldb::eSectionTypeData; break;
case AllocationKind::Bytes: sect_type = lldb::eSectionTypeOther; break;
}
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 (!name.empty())
{
if (name.equals("__text") || name.equals(".text"))
sect_type = lldb::eSectionTypeCode;
else if (name.equals("__data") || name.equals(".data"))
sect_type = lldb::eSectionTypeCode;
else if (name.startswith("__debug_") || name.startswith(".debug_"))
{
const uint32_t name_idx = name[0] == '_' ? 8 : 7;
llvm::StringRef dwarf_name(name.substr(name_idx));
switch (dwarf_name[0])
{
case 'a':
if (dwarf_name.equals("abbrev"))
sect_type = lldb::eSectionTypeDWARFDebugAbbrev;
else if (dwarf_name.equals("aranges"))
sect_type = lldb::eSectionTypeDWARFDebugAranges;
Add support for DW_FORM_GNU_[addr,str]_index These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
2015-08-25 19:45:58 +08:00
else if (dwarf_name.equals("addr"))
sect_type = lldb::eSectionTypeDWARFDebugAddr;
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 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 'f':
if (dwarf_name.equals("frame"))
sect_type = lldb::eSectionTypeDWARFDebugFrame;
break;
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 'i':
if (dwarf_name.equals("info"))
sect_type = lldb::eSectionTypeDWARFDebugInfo;
break;
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 'l':
if (dwarf_name.equals("line"))
sect_type = lldb::eSectionTypeDWARFDebugLine;
else if (dwarf_name.equals("loc"))
sect_type = lldb::eSectionTypeDWARFDebugLoc;
break;
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 'm':
if (dwarf_name.equals("macinfo"))
sect_type = lldb::eSectionTypeDWARFDebugMacInfo;
break;
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 'p':
if (dwarf_name.equals("pubnames"))
sect_type = lldb::eSectionTypeDWARFDebugPubNames;
else if (dwarf_name.equals("pubtypes"))
sect_type = lldb::eSectionTypeDWARFDebugPubTypes;
break;
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 's':
if (dwarf_name.equals("str"))
sect_type = lldb::eSectionTypeDWARFDebugStr;
Add support for DW_FORM_GNU_[addr,str]_index These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
2015-08-25 19:45:58 +08:00
else if (dwarf_name.equals("str_offsets"))
sect_type = lldb::eSectionTypeDWARFDebugStrOffsets;
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 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 'r':
if (dwarf_name.equals("ranges"))
sect_type = lldb::eSectionTypeDWARFDebugRanges;
break;
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
default:
break;
}
}
else if (name.startswith("__apple_") || name.startswith(".apple_"))
{
#if 0
const uint32_t name_idx = name[0] == '_' ? 8 : 7;
llvm::StringRef apple_name(name.substr(name_idx));
switch (apple_name[0])
{
case 'n':
if (apple_name.equals("names"))
sect_type = lldb::eSectionTypeDWARFAppleNames;
else if (apple_name.equals("namespac") || apple_name.equals("namespaces"))
sect_type = lldb::eSectionTypeDWARFAppleNamespaces;
break;
case 't':
if (apple_name.equals("types"))
sect_type = lldb::eSectionTypeDWARFAppleTypes;
break;
case 'o':
if (apple_name.equals("objc"))
sect_type = lldb::eSectionTypeDWARFAppleObjC;
break;
default:
break;
}
#else
sect_type = lldb::eSectionTypeInvalid;
#endif
}
else if (name.equals("__objc_imageinfo"))
sect_type = lldb::eSectionTypeOther;
}
return sect_type;
}
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
uint8_t *
IRExecutionUnit::MemoryManager::allocateCodeSection(uintptr_t Size,
unsigned Alignment,
Fix build after LLVM memory management API changes. llvm-svn: 191806
2013-10-02 09:43:46 +08:00
unsigned SectionID,
llvm::StringRef SectionName)
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
{
<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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fix build after LLVM memory management API changes. llvm-svn: 191806
2013-10-02 09:43:46 +08:00
uint8_t *return_value = m_default_mm_ap->allocateCodeSection(Size, Alignment, SectionID, SectionName);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_parent.m_records.push_back(AllocationRecord((uintptr_t)return_value,
Fixed the way we allocate executable memory on behalf of the JIT. We don't need it to be writable since we are using special APIs to write into it. <rdar://problem/13599185> llvm-svn: 179077
2013-04-09 09:13:08 +08:00
lldb::ePermissionsReadable | lldb::ePermissionsExecutable,
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
GetSectionTypeFromSectionName (SectionName, AllocationKind::Code),
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Size,
Alignment,
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
SectionID,
SectionName.str().c_str()));
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 (log)
{
log->Printf("IRExecutionUnit::allocateCodeSection(Size=0x%" PRIx64 ", Alignment=%u, SectionID=%u) = %p",
Fix -Wformat-pedantic warnings llvm-svn: 234429
2015-04-09 04:23:52 +08:00
(uint64_t)Size, Alignment, SectionID, (void *)return_value);
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
}
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
if (m_parent.m_reported_allocations)
{
Error err;
lldb::ProcessSP process_sp = m_parent.GetBestExecutionContextScope()->CalculateProcess();
m_parent.CommitOneAllocation(process_sp, err, m_parent.m_records.back());
}
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
return return_value;
}
uint8_t *
IRExecutionUnit::MemoryManager::allocateDataSection(uintptr_t Size,
unsigned Alignment,
unsigned SectionID,
Fix build after LLVM memory management API changes. llvm-svn: 191806
2013-10-02 09:43:46 +08:00
llvm::StringRef SectionName,
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
bool IsReadOnly)
{
<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
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
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
Fix build after LLVM memory management API changes. llvm-svn: 191806
2013-10-02 09:43:46 +08:00
uint8_t *return_value = m_default_mm_ap->allocateDataSection(Size, Alignment, SectionID, SectionName, IsReadOnly);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed a ton of gcc compile warnings Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
2015-05-13 08:25:54 +08:00
uint32_t permissions = lldb::ePermissionsReadable;
if (!IsReadOnly)
permissions |= lldb::ePermissionsWritable;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
m_parent.m_records.push_back(AllocationRecord((uintptr_t)return_value,
Fixed a ton of gcc compile warnings Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
2015-05-13 08:25:54 +08:00
permissions,
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
GetSectionTypeFromSectionName (SectionName, AllocationKind::Data),
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
Size,
Alignment,
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
SectionID,
SectionName.str().c_str()));
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 (log)
{
log->Printf("IRExecutionUnit::allocateDataSection(Size=0x%" PRIx64 ", Alignment=%u, SectionID=%u) = %p",
Fix -Wformat-pedantic warnings llvm-svn: 234429
2015-04-09 04:23:52 +08:00
(uint64_t)Size, Alignment, SectionID, (void *)return_value);
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
}
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
if (m_parent.m_reported_allocations)
{
Error err;
lldb::ProcessSP process_sp = m_parent.GetBestExecutionContextScope()->CalculateProcess();
m_parent.CommitOneAllocation(process_sp, err, m_parent.m_records.back());
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
return return_value;
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
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
static ConstString
FindBestAlternateMangledName(const ConstString &demangled,
const lldb::LanguageType &lang_type,
const SymbolContext &sym_ctx)
{
CPlusPlusLanguage::MethodName cpp_name(demangled);
std::string scope_qualified_name = cpp_name.GetScopeQualifiedName();
if (!scope_qualified_name.size())
return ConstString();
if (!sym_ctx.module_sp)
return ConstString();
SymbolVendor *sym_vendor = sym_ctx.module_sp->GetSymbolVendor();
if (!sym_vendor)
return ConstString();
lldb_private::SymbolFile *sym_file = sym_vendor->GetSymbolFile();
if (!sym_file)
return ConstString();
std::vector<ConstString> alternates;
sym_file->GetMangledNamesForFunction(scope_qualified_name, alternates);
std::vector<ConstString> param_and_qual_matches;
std::vector<ConstString> param_matches;
for (size_t i = 0; i < alternates.size(); i++)
{
ConstString alternate_mangled_name = alternates[i];
Mangled mangled(alternate_mangled_name, true);
ConstString demangled = mangled.GetDemangledName(lang_type);
CPlusPlusLanguage::MethodName alternate_cpp_name(demangled);
if (!cpp_name.IsValid())
continue;
if (alternate_cpp_name.GetArguments() == cpp_name.GetArguments())
{
if (alternate_cpp_name.GetQualifiers() == cpp_name.GetQualifiers())
param_and_qual_matches.push_back(alternate_mangled_name);
else
param_matches.push_back(alternate_mangled_name);
}
}
if (param_and_qual_matches.size())
return param_and_qual_matches[0]; // It is assumed that there will be only one!
else if (param_matches.size())
return param_matches[0]; // Return one of them as a best match
else
return ConstString();
}
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
struct IRExecutionUnit::SearchSpec
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
ConstString name;
uint32_t mask;
Fixed a problem where we couldn't call extern "C" functions. Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB has to fall back (if it is about to give up finding a symbol) to using the base name of the function. This fix also ensures that we search by full name rather than "auto," which could cause unrelated C++ names to be found. Finally, it adds a test case. <rdar://problem/25094302> llvm-svn: 271551
2016-06-03 01:59:47 +08:00
SearchSpec(ConstString n, uint32_t m = lldb::eFunctionNameTypeFull) :
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
name(n),
mask(m)
{
}
};
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
void
IRExecutionUnit::CollectCandidateCNames(std::vector<IRExecutionUnit::SearchSpec> &C_specs, const ConstString &name)
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
if (m_strip_underscore && name.AsCString()[0] == '_')
C_specs.insert(C_specs.begin(), ConstString(&name.AsCString()[1]));
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
C_specs.push_back(SearchSpec(name));
}
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
void
IRExecutionUnit::CollectCandidateCPlusPlusNames(std::vector<IRExecutionUnit::SearchSpec> &CPP_specs, const std::vector<SearchSpec> &C_specs, const SymbolContext &sc)
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
for (const SearchSpec &C_spec : C_specs)
{
const ConstString &name = C_spec.name;
if (CPlusPlusLanguage::IsCPPMangledName(name.GetCString()))
{
Mangled mangled(name, true);
ConstString demangled = mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (demangled)
{
ConstString best_alternate_mangled_name = FindBestAlternateMangledName(demangled, lldb::eLanguageTypeC_plus_plus, sc);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (best_alternate_mangled_name)
{
CPP_specs.push_back(best_alternate_mangled_name);
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
CPP_specs.push_back(SearchSpec(demangled, lldb::eFunctionNameTypeFull));
}
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
// Maybe we're looking for a const symbol but the debug info told us it was const...
if (!strncmp(name.GetCString(), "_ZN", 3) &&
strncmp(name.GetCString(), "_ZNK", 4))
{
std::string fixed_scratch("_ZNK");
fixed_scratch.append(name.GetCString() + 3);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
// Maybe we're looking for a static symbol but we thought it was global...
if (!strncmp(name.GetCString(), "_Z", 2) &&
strncmp(name.GetCString(), "_ZL", 3))
{
std::string fixed_scratch("_ZL");
fixed_scratch.append(name.GetCString() + 2);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
}
}
Fixed a problem where we couldn't call extern "C" functions. Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB has to fall back (if it is about to give up finding a symbol) to using the base name of the function. This fix also ensures that we search by full name rather than "auto," which could cause unrelated C++ names to be found. Finally, it adds a test case. <rdar://problem/25094302> llvm-svn: 271551
2016-06-03 01:59:47 +08:00
void
IRExecutionUnit::CollectFallbackNames(std::vector<SearchSpec> &fallback_specs,
const std::vector<SearchSpec> &C_specs)
{
// As a last-ditch fallback, try the base name for C++ names. It's terrible,
// but the DWARF doesn't always encode "extern C" correctly.
for (const SearchSpec &C_spec : C_specs)
{
const ConstString &name = C_spec.name;
if (CPlusPlusLanguage::IsCPPMangledName(name.GetCString()))
{
Mangled mangled_name(name);
ConstString demangled_name = mangled_name.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
if (!demangled_name.IsEmpty())
{
const char *demangled_cstr = demangled_name.AsCString();
const char *lparen_loc = strchr(demangled_cstr, '(');
if (lparen_loc)
{
llvm::StringRef base_name(demangled_cstr, lparen_loc-demangled_cstr);
fallback_specs.push_back(ConstString(base_name));
}
}
}
}
}
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
lldb::addr_t
IRExecutionUnit::FindInSymbols(const std::vector<IRExecutionUnit::SearchSpec> &specs, const lldb_private::SymbolContext &sc)
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
Target *target = sc.target_sp.get();
if (!target)
{
// we shouldn't be doing any symbol lookup at all without a target
return LLDB_INVALID_ADDRESS;
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
for (const SearchSpec &spec : specs)
{
SymbolContextList sc_list;
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
lldb::addr_t best_internal_load_address = LLDB_INVALID_ADDRESS;
std::function<bool (lldb::addr_t &, SymbolContextList &, const lldb_private::SymbolContext &)> get_external_load_address =
[&best_internal_load_address, target](lldb::addr_t &load_address,
SymbolContextList &sc_list,
const lldb_private::SymbolContext &sc) -> lldb::addr_t
{
load_address = LLDB_INVALID_ADDRESS;
for (size_t si = 0, se = sc_list.GetSize(); si < se; ++si)
{
SymbolContext candidate_sc;
sc_list.GetContextAtIndex(si, candidate_sc);
const bool is_external = (candidate_sc.function) ||
(candidate_sc.symbol && candidate_sc.symbol->IsExternal());
Fix "ninja check-lldb" crash in IRExecutionUnit.cpp Summary: From Adrian McCarthy: "Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer." Reviewers: zturner, spyffe, amccarth Subscribers: ted, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D17860 llvm-svn: 263066
2016-03-10 06:05:17 +08:00
if (candidate_sc.symbol)
{
load_address = candidate_sc.symbol->ResolveCallableAddress(*target);
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
Fix "ninja check-lldb" crash in IRExecutionUnit.cpp Summary: From Adrian McCarthy: "Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer." Reviewers: zturner, spyffe, amccarth Subscribers: ted, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D17860 llvm-svn: 263066
2016-03-10 06:05:17 +08:00
if (load_address == LLDB_INVALID_ADDRESS)
{
if (target->GetProcessSP())
load_address = candidate_sc.symbol->GetAddress().GetLoadAddress(target);
else
load_address = candidate_sc.symbol->GetAddress().GetFileAddress();
}
}
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
Fix "ninja check-lldb" crash in IRExecutionUnit.cpp Summary: From Adrian McCarthy: "Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer." Reviewers: zturner, spyffe, amccarth Subscribers: ted, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D17860 llvm-svn: 263066
2016-03-10 06:05:17 +08:00
if (load_address == LLDB_INVALID_ADDRESS && candidate_sc.function)
Fix warning in IRExecutionUnit.cpp llvm-svn: 262712
2016-03-04 19:26:56 +08:00
{
Fix "ninja check-lldb" crash in IRExecutionUnit.cpp Summary: From Adrian McCarthy: "Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer." Reviewers: zturner, spyffe, amccarth Subscribers: ted, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D17860 llvm-svn: 263066
2016-03-10 06:05:17 +08:00
if (target->GetProcessSP())
load_address = candidate_sc.function->GetAddressRange().GetBaseAddress().GetLoadAddress(target);
else
load_address = candidate_sc.function->GetAddressRange().GetBaseAddress().GetFileAddress();
Fix warning in IRExecutionUnit.cpp llvm-svn: 262712
2016-03-04 19:26:56 +08:00
}
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
if (load_address != LLDB_INVALID_ADDRESS)
{
if (is_external)
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
{
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
return true;
}
else if (best_internal_load_address == LLDB_INVALID_ADDRESS)
{
best_internal_load_address = load_address;
load_address = LLDB_INVALID_ADDRESS;
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
}
}
}
return false;
};
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (sc.module_sp)
{
sc.module_sp->FindFunctions(spec.name,
NULL,
spec.mask,
true, // include_symbols
false, // include_inlines
true, // append
sc_list);
}
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
lldb::addr_t load_address = LLDB_INVALID_ADDRESS;
if (get_external_load_address(load_address, sc_list, sc))
{
return load_address;
}
else
{
sc_list.Clear();
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (sc_list.GetSize() == 0 && sc.target_sp)
{
sc.target_sp->GetImages().FindFunctions(spec.name,
spec.mask,
true, // include_symbols
false, // include_inlines
true, // append
sc_list);
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
if (get_external_load_address(load_address, sc_list, sc))
{
return load_address;
}
else
{
sc_list.Clear();
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (sc_list.GetSize() == 0 && sc.target_sp)
{
sc.target_sp->GetImages().FindSymbolsWithNameAndType(spec.name, lldb::eSymbolTypeAny, sc_list);
}
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
if (get_external_load_address(load_address, sc_list, sc))
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
return load_address;
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
}
When looking for symbols, find load addresses in a more robust way. IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
2016-02-24 07:09:06 +08:00
// if there are any searches we try after this, add an sc_list.Clear() in an "else" clause here
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (best_internal_load_address != LLDB_INVALID_ADDRESS)
{
return best_internal_load_address;
}
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
return LLDB_INVALID_ADDRESS;
}
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
lldb::addr_t
IRExecutionUnit::FindInRuntimes(const std::vector<SearchSpec> &specs, const lldb_private::SymbolContext &sc)
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
lldb::TargetSP target_sp = sc.target_sp;
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
if (!target_sp)
{
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
return LLDB_INVALID_ADDRESS;
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
lldb::ProcessSP process_sp = sc.target_sp->GetProcessSP();
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (!process_sp)
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
{
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
return LLDB_INVALID_ADDRESS;
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
ObjCLanguageRuntime *runtime = process_sp->GetObjCLanguageRuntime();
if (runtime)
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
{
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
for (const SearchSpec &spec : specs)
{
lldb::addr_t symbol_load_addr = runtime->LookupRuntimeSymbol(spec.name);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (symbol_load_addr != LLDB_INVALID_ADDRESS)
return symbol_load_addr;
}
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
return LLDB_INVALID_ADDRESS;
}
Make sure we can lookup re-exported symbols after recent changes to lldb_private::Symbol. Recently lldb_private::Symbol was changed so the old code: Address &Symbol::GetAddress(); Is now: Address Symbol::GetAddress(); And the Address object that is returned will be invalid for non-address based symbols. When we have re-exported symbols this code would now fail: const Address sym_address = sym_ctx.symbol->GetAddress(); if (!sym_address.IsValid()) continue; symbol_load_addr = sym_ctx.symbol->ResolveCallableAddress(*target_sp); if (symbol_load_addr == LLDB_INVALID_ADDRESS) { symbol_load_addr = sym_address.GetLoadAddress(target_sp.get()); } It used to return an Address reference to the value of the re-exported symbol that contained no section and a zero value for Address.m_offset (since the original symbol in the symbol table had a value of zero). When a reference was returned, this meant the "sym_address.IsValid()" would return true because the Address.m_offset was not LLDB_INVALID_ADDRESS, it was zero. This was working by mistake. The Symbol::ResolveCallableAddress(...) actually checks for reexported symbols and whole bunch of other cases and resolves the address correctly, so we should let it do its thing and not cut it off before it can resolve the address with the "if (!sym_address.IsValid()) continue;". llvm-svn: 241282
2015-07-03 00:43:49 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
lldb::addr_t
IRExecutionUnit::FindInUserDefinedSymbols(const std::vector<SearchSpec> &specs, const lldb_private::SymbolContext &sc)
{
lldb::TargetSP target_sp = sc.target_sp;
for (const SearchSpec &spec : specs)
{
lldb::addr_t symbol_load_addr = target_sp->GetPersistentSymbol(spec.name);
if (symbol_load_addr != LLDB_INVALID_ADDRESS)
return symbol_load_addr;
}
return LLDB_INVALID_ADDRESS;
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
lldb::addr_t
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
IRExecutionUnit::FindSymbol(const lldb_private::ConstString &name)
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
{
std::vector<SearchSpec> candidate_C_names;
std::vector<SearchSpec> candidate_CPlusPlus_names;
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
CollectCandidateCNames(candidate_C_names, name);
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
lldb::addr_t ret = FindInSymbols(candidate_C_names, m_sym_ctx);
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (ret == LLDB_INVALID_ADDRESS)
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
ret = FindInRuntimes(candidate_C_names, m_sym_ctx);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
if (ret == LLDB_INVALID_ADDRESS)
ret = FindInUserDefinedSymbols(candidate_C_names, m_sym_ctx);
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (ret == LLDB_INVALID_ADDRESS)
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
{
Fix stripping of _ when looking for symbols in IRExecutionUnit. Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
2016-02-13 07:55:13 +08:00
CollectCandidateCPlusPlusNames(candidate_CPlusPlus_names, candidate_C_names, m_sym_ctx);
ret = FindInSymbols(candidate_CPlusPlus_names, m_sym_ctx);
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
Fixed a problem where we couldn't call extern "C" functions. Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB has to fall back (if it is about to give up finding a symbol) to using the base name of the function. This fix also ensures that we search by full name rather than "auto," which could cause unrelated C++ names to be found. Finally, it adds a test case. <rdar://problem/25094302> llvm-svn: 271551
2016-06-03 01:59:47 +08:00
if (ret == LLDB_INVALID_ADDRESS)
{
std::vector<SearchSpec> candidate_fallback_names;
CollectFallbackNames(candidate_fallback_names, candidate_C_names);
ret = FindInSymbols(candidate_fallback_names, m_sym_ctx);
}
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
return ret;
}
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
void
IRExecutionUnit::GetStaticInitializers(std::vector <lldb::addr_t> &static_initializers)
{
if (llvm::GlobalVariable *global_ctors = m_module->getNamedGlobal("llvm.global_ctors"))
{
if (llvm::ConstantArray *ctor_array = llvm::dyn_cast<llvm::ConstantArray>(global_ctors->getInitializer()))
{
for (llvm::Use &ctor_use : ctor_array->operands())
{
if (llvm::ConstantStruct *ctor_struct = llvm::dyn_cast<llvm::ConstantStruct>(ctor_use))
{
lldbassert(ctor_struct->getNumOperands() == 3); // this is standardized
if (llvm::Function *ctor_function = llvm::dyn_cast<llvm::Function>(ctor_struct->getOperand(1)))
{
ctor_function->dump();
ConstString ctor_function_name_cs(ctor_function->getName().str());
for (JittedFunction &jitted_function : m_jitted_functions)
{
if (ctor_function_name_cs == jitted_function.m_name)
{
if (jitted_function.m_remote_addr != LLDB_INVALID_ADDRESS)
{
static_initializers.push_back(jitted_function.m_remote_addr);
}
break;
}
}
}
}
}
}
}
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
uint64_t
IRExecutionUnit::MemoryManager::getSymbolAddress(const std::string &Name)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
ConstString name_cs(Name.c_str());
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
lldb::addr_t ret = m_parent.FindSymbol(name_cs);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
if (ret == LLDB_INVALID_ADDRESS)
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
{
if (log)
log->Printf("IRExecutionUnit::getSymbolAddress(Name=\"%s\") = <not found>",
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
Name.c_str());
m_parent.ReportSymbolLookupError(name_cs);
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
return 0xbad0bad0;
}
Centralized symbol lookup in IRExecutionUnit, and fixed the code model. I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
2016-02-13 05:11:25 +08:00
else
{
if (log)
log->Printf("IRExecutionUnit::getSymbolAddress(Name=\"%s\") = %" PRIx64,
Name.c_str(),
ret);
return ret;
}
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
}
void *
IRExecutionUnit::MemoryManager::getPointerToNamedFunction(const std::string &Name,
bool AbortOnFailure) {
assert (sizeof(void *) == 8);
Fix TestCStrings for Linux with i386 inferiors. Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
2016-02-24 11:15:21 +08:00
The MCJIT doesn't seem to call getPointerForNamedFunction from the MemoryManager anymore, switching to getSymbolAddress, which it does call, and implementing it so that we once again look up external symbols in the JIT. Also juked the error reporting from the JIT a little bit. This resolves: http://llvm.org/bugs/show_bug.cgi?id=22314 llvm-svn: 227217
2015-01-28 02:03:05 +08:00
return (void*)getSymbolAddress(Name);
}
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
IRExecutionUnit::GetRemoteAddressForLocal (lldb::addr_t local_address)
{
Fixed IRExecutionUnit so that it looks up addresses correctly. We have been getting lucky since most expressions generate only one section (or the first code section contains all the code), but sometimes it actually matters. <rdar://problem/14180236> llvm-svn: 185054
2013-06-27 09:42:47 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (AllocationRecord &record : m_records)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (local_address >= record.m_host_address &&
local_address < record.m_host_address + record.m_size)
{
if (record.m_process_address == LLDB_INVALID_ADDRESS)
return LLDB_INVALID_ADDRESS;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRExecutionUnit so that it looks up addresses correctly. We have been getting lucky since most expressions generate only one section (or the first code section contains all the code), but sometimes it actually matters. <rdar://problem/14180236> llvm-svn: 185054
2013-06-27 09:42:47 +08:00
lldb::addr_t ret = record.m_process_address + (local_address - record.m_host_address);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRExecutionUnit so that it looks up addresses correctly. We have been getting lucky since most expressions generate only one section (or the first code section contains all the code), but sometimes it actually matters. <rdar://problem/14180236> llvm-svn: 185054
2013-06-27 09:42:47 +08:00
if (log)
{
log->Printf("IRExecutionUnit::GetRemoteAddressForLocal() found 0x%" PRIx64 " in [0x%" PRIx64 "..0x%" PRIx64 "], and returned 0x%" PRIx64 " from [0x%" PRIx64 "..0x%" PRIx64 "].",
local_address,
clean up about 22 warnings messages llvm-svn: 187900
2013-08-08 03:05:15 +08:00
(uint64_t)record.m_host_address,
(uint64_t)record.m_host_address + (uint64_t)record.m_size,
Fixed IRExecutionUnit so that it looks up addresses correctly. We have been getting lucky since most expressions generate only one section (or the first code section contains all the code), but sometimes it actually matters. <rdar://problem/14180236> llvm-svn: 185054
2013-06-27 09:42:47 +08:00
ret,
record.m_process_address,
record.m_process_address + record.m_size);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Fixed IRExecutionUnit so that it looks up addresses correctly. We have been getting lucky since most expressions generate only one section (or the first code section contains all the code), but sometimes it actually matters. <rdar://problem/14180236> llvm-svn: 185054
2013-06-27 09:42:47 +08:00
return ret;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
}
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
}
return LLDB_INVALID_ADDRESS;
}
IRExecutionUnit::AddrRange
IRExecutionUnit::GetRemoteRangeForLocal (lldb::addr_t local_address)
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (AllocationRecord &record : m_records)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (local_address >= record.m_host_address &&
local_address < record.m_host_address + record.m_size)
{
if (record.m_process_address == LLDB_INVALID_ADDRESS)
return AddrRange(0, 0);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
return AddrRange(record.m_process_address, record.m_size);
}
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
}
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
return AddrRange (0, 0);
}
bool
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
IRExecutionUnit::CommitOneAllocation (lldb::ProcessSP &process_sp,
Error &error,
AllocationRecord &record)
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
{
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
if (record.m_process_address != LLDB_INVALID_ADDRESS)
{
return true;
}
switch (record.m_sect_type)
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
{
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 lldb::eSectionTypeInvalid:
case lldb::eSectionTypeDWARFDebugAbbrev:
Add support for DW_FORM_GNU_[addr,str]_index These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
2015-08-25 19:45:58 +08:00
case lldb::eSectionTypeDWARFDebugAddr:
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 lldb::eSectionTypeDWARFDebugAranges:
case lldb::eSectionTypeDWARFDebugFrame:
case lldb::eSectionTypeDWARFDebugInfo:
case lldb::eSectionTypeDWARFDebugLine:
case lldb::eSectionTypeDWARFDebugLoc:
case lldb::eSectionTypeDWARFDebugMacInfo:
case lldb::eSectionTypeDWARFDebugPubNames:
case lldb::eSectionTypeDWARFDebugPubTypes:
case lldb::eSectionTypeDWARFDebugRanges:
case lldb::eSectionTypeDWARFDebugStr:
Add support for DW_FORM_GNU_[addr,str]_index These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
2015-08-25 19:45:58 +08:00
case lldb::eSectionTypeDWARFDebugStrOffsets:
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 lldb::eSectionTypeDWARFAppleNames:
case lldb::eSectionTypeDWARFAppleTypes:
case lldb::eSectionTypeDWARFAppleNamespaces:
case lldb::eSectionTypeDWARFAppleObjC:
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
error.Clear();
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;
default:
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
const bool zero_memory = false;
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
record.m_process_address = Malloc (record.m_size,
record.m_alignment,
record.m_permissions,
eAllocationPolicyProcessOnly,
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
zero_memory,
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
error);
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;
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
}
return error.Success();
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
bool
IRExecutionUnit::CommitAllocations (lldb::ProcessSP &process_sp)
{
bool ret = true;
lldb_private::Error err;
for (AllocationRecord &record : m_records)
{
ret = CommitOneAllocation(process_sp, err, record);
if (!ret)
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
{
break;
}
}
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 (!ret)
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (AllocationRecord &record : m_records)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (record.m_process_address != LLDB_INVALID_ADDRESS)
{
Free(record.m_process_address, err);
record.m_process_address = LLDB_INVALID_ADDRESS;
}
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
}
}
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
return ret;
}
void
IRExecutionUnit::ReportAllocations (llvm::ExecutionEngine &engine)
{
Collect IRExecutionUnits as part of persistent expression state. IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
2016-03-22 06:23:38 +08:00
m_reported_allocations = true;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (AllocationRecord &record : m_records)
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
{
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (record.m_process_address == LLDB_INVALID_ADDRESS)
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
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
if (record.m_section_id == eSectionIDInvalid)
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
continue;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
engine.mapSectionAddress((void*)record.m_host_address, record.m_process_address);
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
}
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
// Trigger re-application of relocations.
engine.finalizeObject();
}
bool
IRExecutionUnit::WriteData (lldb::ProcessSP &process_sp)
{
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
bool wrote_something = false;
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
for (AllocationRecord &record : m_records)
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
{
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 (record.m_process_address != LLDB_INVALID_ADDRESS)
{
lldb_private::Error err;
WriteMemory (record.m_process_address, (uint8_t*)record.m_host_address, record.m_size, err);
if (err.Success())
wrote_something = true;
}
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
}
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 wrote_something;
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
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
void
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
IRExecutionUnit::AllocationRecord::dump (Log *log)
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 (!log)
return;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-07 01:54:58 +08:00
Log information about sections that didn't make it into the target's memory. llvm-svn: 251084
2015-10-23 08:39:09 +08:00
log->Printf("[0x%llx+0x%llx]->0x%llx (alignment %d, section ID %d, name %s)",
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
(unsigned long long)m_host_address,
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
(unsigned long long)m_size,
Factored out memory access into the target process from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
2013-04-05 10:22:57 +08:00
(unsigned long long)m_process_address,
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
(unsigned)m_alignment,
Log information about sections that didn't make it into the target's memory. llvm-svn: 251084
2015-10-23 08:39:09 +08:00
(unsigned)m_section_id,
m_name.c_str());
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
}
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
lldb::ByteOrder
IRExecutionUnit::GetByteOrder () const
{
ExecutionContext exe_ctx (GetBestExecutionContextScope());
return exe_ctx.GetByteOrder();
}
uint32_t
IRExecutionUnit::GetAddressByteSize () const
{
ExecutionContext exe_ctx (GetBestExecutionContextScope());
return exe_ctx.GetAddressByteSize();
}
void
IRExecutionUnit::PopulateSymtab (lldb_private::ObjectFile *obj_file,
lldb_private::Symtab &symtab)
{
// No symbols yet...
}
void
IRExecutionUnit::PopulateSectionList (lldb_private::ObjectFile *obj_file,
lldb_private::SectionList &section_list)
{
for (AllocationRecord &record : m_records)
{
if (record.m_size > 0)
{
lldb::SectionSP section_sp (new lldb_private::Section (obj_file->GetModule(),
obj_file,
record.m_section_id,
ConstString(record.m_name),
record.m_sect_type,
record.m_process_address,
record.m_size,
record.m_host_address, // file_offset (which is the host address for the data)
record.m_size, // file_size
Patch from Keno Fischer to enable JITLoaderGDB with mach-o file support. The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded. llvm-svn: 211638
2014-06-25 06:22:43 +08:00
0,
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
record.m_permissions)); // flags
section_list.AddSection (section_sp);
}
}
}
bool
IRExecutionUnit::GetArchitecture (lldb_private::ArchSpec &arch)
{
ExecutionContext exe_ctx (GetBestExecutionContextScope());
Target *target = exe_ctx.GetTargetPtr();
if (target)
arch = target->GetArchitecture();
else
arch.Clear();
return arch.IsValid();
}
lldb::ModuleSP
IRExecutionUnit::GetJITModule ()
{
ExecutionContext exe_ctx (GetBestExecutionContextScope());
Target *target = exe_ctx.GetTargetPtr();
if (target)
{
lldb::ModuleSP jit_module_sp = lldb_private::Module::CreateJITModule (std::static_pointer_cast<lldb_private::ObjectFileJITDelegate>(shared_from_this()));
if (jit_module_sp)
{
bool changed = false;
jit_module_sp->SetLoadAddress(*target, 0, true, changed);
}
return jit_module_sp;
}
return lldb::ModuleSP();
}