| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 183140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
live as long as they needed to. This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.
To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression. Hand-declared persistent
variables do this now.
<rdar://problem/13956311>
llvm-svn: 182528
|
| |
|
|
|
|
| |
Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression.
llvm-svn: 182066
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mostly related to management of the stack frame
for the interpreter.
- First, if the expression can be interpreted,
allocate the stack frame in the target process
(to make sure pointers are valid) but only
read/write to the copy in the host's memory.
- Second, keep the memory allocations for the
stack frame and the materialized struct as
member variables of ClangUserExpression. This
avoids memory allocations and deallocations
each time the expression runs.
<rdar://problem/13043685>
llvm-svn: 180664
|
| |
|
|
|
|
|
|
|
|
| |
and persistent variables so that they are not
treated as remaining in the target process (i.e.,
having live data) when the process does not allow
persistent allocations (e.g., when there is no
process or in the case of kernel core files).
llvm-svn: 179919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
to make debugging easier when things go wrong.
llvm-svn: 179576
|
| |
|
|
|
|
|
| |
Also improved logging and error handling in a few
spots in the Materializer.
llvm-svn: 179557
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 179445
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
to the Materializer. Materialization is still done by
the ClangExpressionDeclMap; this will be the next thing
to move.
Also fixed a layout bug that this uncovered.
llvm-svn: 179318
|
|
|
information about each variable that needs to
be materialized for an expression to work. The
next step is to migrate all materialization code
from ClangExpressionDeclMap to Materializer, and
to use it for variable materialization.
llvm-svn: 179245
|
