llvm-project/lldb/source
Sean Callanan 1582ee6840 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.

llvm-svn: 179801
2013-04-18 22:06:33 +00:00
..
API Adding new Python API function to check for stopped threads. 2013-04-15 23:33:53 +00:00
Breakpoint 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++. 2013-04-18 18:10:51 +00:00
Commands <rdar://problem/13627061> 2013-04-18 20:17:32 +00:00
Core 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++. 2013-04-18 18:10:51 +00:00
DataFormatters <rdar://problem/13563628> 2013-04-05 18:49:06 +00:00
Expression This commit changes the way LLDB executes user 2013-04-18 22:06:33 +00:00
Host 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++. 2013-04-18 18:10:51 +00:00
Interpreter 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++. 2013-04-18 18:10:51 +00:00
Plugins Missed some cases when switching over to using our STD_UNIQUE_PTR macros. 2013-04-18 21:01:59 +00:00
Symbol 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++. 2013-04-18 18:10:51 +00:00
Target 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++. 2013-04-18 18:10:51 +00:00
Utility Make KQueue import the header in the correct path. 2013-04-18 20:58:20 +00:00
CMakeLists.txt Revert 179694 -- it breaks remote debugging of mac os x targets for some folk 2013-04-17 18:40:42 +00:00
Makefile Remove LLDB dependency on xcodeworkspace (on Linux) for version number 2013-02-28 16:51:15 +00:00
lldb-log.cpp <rdar://problem/13521159> 2013-03-27 23:08:40 +00:00
lldb.cpp Add a new PlatformDarwinKernel for kernel debugging. This Platform 2013-04-05 01:03:25 +00:00