History log of /external/lldb/source/Expression/IRExecutionUnit.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3160832f026e60e832da55f90993a40ad132e360 07-Aug-2013 Michael Sartain <mikesart@valvesoftware.com> clean up about 22 warnings messages

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@187900 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
bc16b9273326b81dc4aae022389a9f8c3bdca66d 31-Jul-2013 Jim Ingham <jingham@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@187473 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
238fab396e150d752701b288a676b2d25667ef79 27-Jun-2013 Sean Callanan <scallanan@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185054 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
779e6ac7d5622ad35f482633b1145c82dbc6c3ce 08-May-2013 Sean Callanan <scallanan@apple.com> Fixed IRExecutionUnit build failures due to changes
in the underlying llvm::JITMemoryManager API.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181387 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
81a96aa6242f7b559770f5dc62316253cb8cb0d4 18-Apr-2013 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
a6686e36cd56843e594139324884585fb47b918b 17-Apr-2013 Sean Callanan <scallanan@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179649 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
faafd193bf7dc065e5f6fb99e4c538cc452af7e4 15-Apr-2013 Sean Callanan <scallanan@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179539 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
0b3cb0effe99bdde8ef9f85dbdf3e38e14f736f6 09-Apr-2013 Sean Callanan <scallanan@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179077 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
9e6f6a6f394bb570c5f1f9a850ec0befe4a59fef 05-Apr-2013 Sean Callanan <scallanan@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
d4f95f3c9462a977f8c15c5062d30bf62cd49110 29-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/11730263>

PC relative loads are missing disassembly comments when disassembled in a live process.

This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.

The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178315 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
914e147661ead8bc8ef9d052797cfb6869c0803d 27-Mar-2013 Sean Callanan <scallanan@apple.com> Fixed a problem where inline assembly errors caused
LLDB to crash.

<rdar://problem/13497915>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178115 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
8202fe26a2a69ccdeab9c49139e9f8c645907dbc 20-Mar-2013 Sean Callanan <scallanan@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177456 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp
1cf3da8b0fb0cabf2431b5fe521842929fca69a3 19-Mar-2013 Sean Callanan <scallanan@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177364 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/IRExecutionUnit.cpp