History log of /external/lldb/source/Expression/Materializer.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
4a4448ba891e48882f8a8c0e891d4fb207a74a0a 13-Jul-2013 Sean Callanan <scallanan@apple.com> Modified the expression parser to only try to
write to registers if they were modified in the
expression. This eliminates spurious errors if
the register can't be written to but the
expression didn't write to it anyway.

Also improved error handling for the materializer
to make "couldn't materialize struct" errors more
informative.

<rdar://problem/14322579>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
52f792329be5db8e38961350589e97e8f2823acd 12-Jul-2013 Greg Clayton <gclayton@apple.com> Huge change to clean up types.

A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186130 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
d0f064d4e5ccef341ecbd6a462bbff5f085a3f77 20-Jun-2013 Sean Callanan <scallanan@apple.com> Fixed a problem with materialization and
dematerialization of registers that caused
conditional breakpoint expressions not to
work properly. Also added a testcase.

<rdar://problem/14129252>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@184451 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
884288bcb6824452a3c64eb772c0976501acc47a 03-Jun-2013 Matt Kopec <Matt.Kopec@intel.com> Fix various build warnings.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@183140 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
e7872343f18b90e4134fb91a616b138ba6bd6b92 23-May-2013 Sean Callanan <scallanan@apple.com> Fixed a bug where persistent variables did not
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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182528 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
668010966e95642360fd12094b28755e5dda5343 17-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13893094>

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182066 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
cdc3ea5398f251d3eca482595f103b1874e51538 27-Apr-2013 Sean Callanan <scallanan@apple.com> Performance optimizations to ClangUserExpression,
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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180664 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
6c7168f14bcd3dac3c6fc584401e36e981f14819 20-Apr-2013 Sean Callanan <scallanan@apple.com> Fixed the expression parser's handling of result
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).


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179919 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
2c810873d43f228341a272000349b2a6f4dcfb5a 19-Apr-2013 Sean Callanan <scallanan@apple.com> Fixed two problems when reading constant/register
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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179876 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
0f0551e67d8ea8d63ace5456f7d42d951827b017 19-Apr-2013 Sean Callanan <scallanan@apple.com> This commit changes the way LLDB executes user
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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179801 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.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/Materializer.cpp
76f9879afa1508febd5538a63a3fad7f01c6c64f 16-Apr-2013 Sean Callanan <scallanan@apple.com> Added logging to each entity in the Materializer
to make debugging easier when things go wrong.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179576 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
973172e84ad0ecb1e5209f6e3c3c824da19b7f21 15-Apr-2013 Sean Callanan <scallanan@apple.com> Added support for registers to the Materializer.
Also improved logging and error handling in a few
spots in the Materializer.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179557 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.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/Materializer.cpp
aa5dca00ffd36aead6cc615c5ed2d74edb9fd84e 13-Apr-2013 Sean Callanan <scallanan@apple.com> Added symbol materialization support to the new
Materializer.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179445 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
e287e900488e20e07ef986ec0524b872fbeafa5d 13-Apr-2013 Sean Callanan <scallanan@apple.com> Now that ValueObjects permit writing, made the
Materializer use that API when dematerializing
variables.


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


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


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179390 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
ce66f96d4329a5664561ceb6f1fc571ed497bcef 11-Apr-2013 Sean Callanan <scallanan@apple.com> Hand over the job of laying out the argument structure
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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179318 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/Materializer.cpp
3b16eb9d424068446fea9cd0e0fe5e7d435f5b6e 11-Apr-2013 Sean Callanan <scallanan@apple.com> Added a Materializer class that contains
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.


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