Commit Graph

9 Commits

Author SHA1 Message Date
Sean Callanan 08052afa2d Updated the IRInterpreter to work with an
IRMemoryMap rather than through its own memory
abstraction.  This considerably simplifies the
code, and makes it possible to run the
IRInterpreter multiple times on an already-parsed
expression in the absence of a ClangExpressionDeclMap.

Changes include:

  - ClangExpressionDeclMap's interface methods
    for the IRInterpreter now take IRMemoryMap
    arguments.  They are not long for this world,
    however, since the IRInterpreter will soon be
    working with materialized variables.

  - As mentioned above, removed the Memory class
    from the IR interpreter altogether.  It had a
    few functions that remain useful, such as
    keeping track of Values that have been placed
    in memory, so I moved those into methods on
    InterpreterStackFrame.

  - Changed IRInterpreter to work with lldb::addr_t
    rather than Memory::Region as its primary
    currency.

  - Fixed a bug in the IRMemoryMap where it did not
    report correct address byte size and byte order
    if no process was present, because it was using
    Target::GetDefaultArchitecture() rather than
    Target::GetArchitecture().

  - Made IRMemoryMap methods clear the Errors they
    receive before running.  Having to do this by
    hand is just annoying.

The testsuite seems happy with these changes, but
please let me know if you see problems (especially
in use cases without a process).

llvm-svn: 179675
2013-04-17 07:50:58 +00:00
Sean Callanan 14b1bae5ee 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-16 23:25:35 +00:00
Sean Callanan 2d37e5a5a5 Added logging to each entity in the Materializer
to make debugging easier when things go wrong.

llvm-svn: 179576
2013-04-15 22:48:23 +00:00
Sean Callanan c8c5b8dcd7 Fixed a few bugs in IRMemoryMap:
- If an allocation is mirrored between the host
  and the process, update the host's version
  before returning a DataExtractor pointing to
  it.

- If anyone attempts to access memory in a
  process/target that does not have a corresponding
  allocation, try accessing the memory directly
  before erroring out.

llvm-svn: 179561
2013-04-15 21:35:52 +00:00
Sean Callanan b024d87822 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-15 17:12:47 +00:00
Sean Callanan 458ae1c6eb Now that ValueObjects permit writing, made the
Materializer use that API when dematerializing
variables.

llvm-svn: 179443
2013-04-13 02:06:42 +00:00
Sean Callanan f8043fa527 Implemented materialization and dematerialization
for variables in the new Materializer.  This is
much easier now that the ValueObject API is solid.

I still have to implement reading bytes into a
ValueObject, but committing what I have so far.

This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.

llvm-svn: 179416
2013-04-12 21:40:34 +00:00
Sean Callanan 35005f768e Replicated the materialization logic for persistent
variables in the Materializer.  We don't use this
code yet, but will soon once the other materializers
are online.

llvm-svn: 179390
2013-04-12 18:10:34 +00:00
Sean Callanan 5a1af4e63a 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 02:22:57 +00:00