| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Materializer use that API when dematerializing
variables.
llvm-svn: 179443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for variables in the new Materializer. This is
much easier now that the ValueObject API is solid.
I still have to implement reading bytes into a
ValueObject, but committing what I have so far.
This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.
llvm-svn: 179416
|
| |
|
|
|
|
|
|
| |
variables in the Materializer. We don't use this
code yet, but will soon once the other materializers
are online.
llvm-svn: 179390
|
|
|
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
|
