History log of /external/lldb/include/lldb/Expression/ClangExpressionParser.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
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/include/lldb/Expression/ClangExpressionParser.h
81a96aa6242f7b559770f5dc62316253cb8cb0d4 18-Apr-2013 Greg Clayton <gclayton@apple.com> 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++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
9e6f6a6f394bb570c5f1f9a850ec0befe4a59fef 05-Apr-2013 Sean Callanan <scallanan@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
1cf3da8b0fb0cabf2431b5fe521842929fca69a3 19-Mar-2013 Sean Callanan <scallanan@apple.com> Refactored the expression parser so that the IR
and the JITted code are managed by a standalone
class that handles memory management itself.

I have removed RecordingMemoryManager and
ProcessDataAllocator, which filled similar roles
and had confusing ownership, with a common class
called IRExecutionUnit. The IRExecutionUnit
manages all allocations ever made for an expression
and frees them when it goes away. It also contains
the code generator and can vend the Module for an
expression to other clases.

The end goal here is to make the output of the
expression parser re-usable; that is, to avoid
re-parsing when re-parsing isn't necessary.

I've also cleaned up some code and used weak pointers
in more places. Please let me know if you see any
leaks; I checked myself as well but I might have
missed a case.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177364 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
ddf110d67eb3d3e621441c4383904e838bc0c403 24-Jan-2012 Sean Callanan <scallanan@apple.com> Added a mechanism for the IR interpreter to return
an error along with its boolean result. The
expression parser reports this error if the
interpreter fails and the expression could not be
run in the target.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148870 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
47dc457387b690c5e4df1c0c7dd8c4337b92e630 15-Sep-2011 Sean Callanan <scallanan@apple.com> This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.

This modification touches the following files:

lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.

Target.[h,cpp]
Have EvaluateExpression now accept the new enum.

ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.

ClangFunction.[cpp,h]
Add support for the new enum.

IRInterpreter.[cpp,h]
New implementation.

ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.

ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.

ClangUtilityFunction.[cpp,h]
Add support for the new enum.

ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.

IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.

IRToDWARF.cpp
Removed

CommandObjectExpression.cpp
Remove references to the obsolete -i option.

Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)

SBValue.cpp
Add support for the new enum.

SBFrame.cpp
Add support for he new enum.

BreakpointOptions.cpp
Add support for the new enum.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139772 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
c0492741dc594cd02736521048fe0d8f4c9a0a61 23-May-2011 Sean Callanan <scallanan@apple.com> This commit integrates support for the LLVM MCJIT
into the mainline LLDB codebase. MCJIT introduces
API improvements and better architectural support.

This commit adds a new subsystem, the
ProcessDataAllocator, which is responsible for
performing static data allocations on behalf of the
IR transformer. MCJIT currently does not support
the relocations required to store the constant pool
in the same allocation as the function body, so we
allocate a heap region separately and redirect
static data references from the expression to that
heap region in a new IR modification pass.

This patch also fixes bugs in the IR
transformations that were exposed by the transition
to the MCJIT. Finally, the patch also pulls in a
more recent revision of LLVM so that the MCJIT is
available for use.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131923 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
696cf5f6f2a77b87a4b06cdf0f697749b494665f 07-May-2011 Sean Callanan <scallanan@apple.com> Made expressions that are just casts of pointer
variables be evaluated statically.

Also fixed a bug that caused the results of
statically-evaluated expressions to be materialized
improperly.

This bug also removes some duplicate code.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131042 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
b344843f75ef893762c93fd0a22d2d45712ce74d 24-Mar-2011 Greg Clayton <gclayton@apple.com> Fixed the LLDB build so that we can have private types, private enums and
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128239 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
279584cdea3dfda933480ed0fe948df2697ab512 15-Mar-2011 Sean Callanan <scallanan@apple.com> Updated to LLVM/Clang revision 127600.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127634 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
395fc33dc4b06c048ed35047ec461bc092ef2df3 15-Feb-2011 Greg Clayton <gclayton@apple.com> Made lldb_private::ArchSpec contain much more than just an architecture. It
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
d0882d062a09effb7a22ce81cb327e9b9fa108bd 20-Jan-2011 Greg Clayton <gclayton@apple.com> Make expressions clean up their JIT'ed code allocation.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123855 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
c7674af9458fbad6f07fa73609c354abf93af2dc 18-Jan-2011 Sean Callanan <scallanan@apple.com> Added support for the fragile ivars provided by
Apple's Objective-C 2.0 runtime. They are enabled
if the Objective-C runtime has the proper version.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123694 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
05a5a1bcbed5c0f31fed29153bb2912d71836e91 16-Dec-2010 Sean Callanan <scallanan@apple.com> Implemented a feature where the expression parser
can avoid running the code in the target if the
expression's result is known and the expression
has no side effects.

Right now this feature is quite conservative in
its guess about side effects, and it only computes
integer results, but the machinery to make it more
sophisticated is there.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121952 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
22defe8b06df5b1f09b53bda255ef07513abc04c 03-Dec-2010 Greg Clayton <gclayton@apple.com> Updated to latest LLVM/Clang for external AST source changes that allow
TagDecl subclasses and Objective C interfaces to complete themselves through
the ExternalASTSource class.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@120749 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
ee8fc726f2eff9c3b3db7f00f9fddbaa9735e045 19-Nov-2010 Sean Callanan <scallanan@apple.com> Modifications to type handling logic. We no longer
perform recursive type lookups, because these are not
required for full type fidelity. We also make the
SelectorTable last for the full lifetime of the Clang
compiler; this was the source of many bugs.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@119835 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
8a3b0a85dd512824f528cfa55d93f530ebe38be8 18-Nov-2010 Sean Callanan <scallanan@apple.com> Updated to the LLVM/Clang of 2010-11-17 at 3:30pm.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@119677 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
47a5c4c01066ece2d41cba56c3a065eeca12d47c 23-Sep-2010 Sean Callanan <scallanan@apple.com> Updated to latest LLVM. Major LLVM changes:

- Sema is now exported (and there was much rejoicing.)

- Storage classes are now centrally defined.

Also fixed some bugs that the new LLVM picked up.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114622 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
830a903fd7cd4595cf52e1630b6491930ada0400 28-Aug-2010 Sean Callanan <scallanan@apple.com> Added a ClangUtilityFunction class that allows the
debugger to insert self-contained functions for use by
expressions (mainly for error-checking).

In order to support detecting whether a crash occurred
in one of these helpers -- currently our preferred way
of reporting that an error-check failed -- added a bit
of support for getting the extent of a JITted function
in addition to just its base.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112324 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h
65dafa8344c8c018e346dd331a7782081a896239 27-Aug-2010 Sean Callanan <scallanan@apple.com> This is a major refactoring of the expression parser.
The goal is to separate the parser's data from the data
belonging to the parser's clients. This allows clients
to use the parser to obtain (for example) a JIT compiled
function or some DWARF code, and then discard the parser
state.

Previously, parser state was held in ClangExpression and
used liberally by ClangFunction, which inherited from
ClangExpression. The main effects of this refactoring
are:

- reducing ClangExpression to an abstract class that
declares methods that any client must expose to the
expression parser,

- moving the code specific to implementing the "expr"
command from ClangExpression and
CommandObjectExpression into ClangUserExpression,
a new class,

- moving the common parser interaction code from
ClangExpression into ClangExpressionParser, a new
class, and

- making ClangFunction rely only on
ClangExpressionParser and not depend on the
internal implementation of ClangExpression.

Side effects include:

- the compiler interaction code has been factored
out of ClangFunction and is now in an AST pass
(ASTStructExtractor),

- the header file for ClangFunction is now fully
documented,

- several bugs that only popped up when Clang was
deallocated (which never happened, since the
lifetime of the compiler was essentially infinite)
are now fixed, and

- the developer-only "call" command has been
disabled.

I have tested the expr command and the Objective-C
step-into code, which use ClangUserExpression and
ClangFunction, respectively, and verified that they
work. Please let me know if you encounter bugs or
poor documentation.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112249 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/ClangExpressionParser.h