History log of /external/lldb/source/Expression/ClangUtilityFunction.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.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/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
8459ba986e7ddd1539b046648680f2283fde8304 14-Feb-2013 Greg Clayton <gclayton@apple.com> Centralized the expression prefixes that are used for both expressions and utility functions.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175108 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
ce490e3161b17c3f2904d6e797bb5e5517d651c2 13-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13210494>

Parse objective C information as efficiently as possible and without taking dangerous runtime locks.

Reworked the way objective C information is parsed by:
1 - don't read all class names up front, this is about 500K of data with names
2 - add a 32 bit hash map that maps a hash of a name to the Class pointer (isa)
3 - Improved name lookups by using the new hash map
4 - split up reading the objc runtime info into dynamic and shared cache since the shared cache only needs to be read once.
5 - When reading all isa values, also get the 32 bit hash instead of the name
6 - Read names lazily now that we don't need all names up front
7 - Allow the hash maps to not be there and still have this function correctly

There is dead code in here with all of the various methods I tried. I want to check this in first to not lose any of it in case we need to revert to any of the extra code. I will promptly cleanup and commit again.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175101 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
7adfcfdb46018d16393995276699a04505727808 18-Sep-2012 Enrico Granata <egranata@apple.com> Making ClangExpression hold on to a WP to the Process instead of a SP. This fix should enable us to have per-process maps of ClangExpressions without fear of keeping the process alive forever

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164082 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
13d24fb1817faa7ccc4cfd799113ba1a2b8968eb 29-Jan-2012 Greg Clayton <gclayton@apple.com> Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
73b520f4f60dca58e58e446c9504d45384ee677b 29-Oct-2011 Sean Callanan <scallanan@apple.com> I moved the responsibility for interacting with the
AST importer on completing namespace mappings from
ClangExpressionDeclMap to ClangASTSource.

ClangASTSource now contains a TargetSP which it
uses to lookup namespaces in all of a target's
modules. I will use the TargetSP in the future to
look up globals.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143275 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
567e7f3ba16eb48cb9fd6a2f26f2f7269eb6983c 22-Sep-2011 Greg Clayton <gclayton@apple.com> Converted the lldb_private::Process over to use the intrusive
shared pointers.

Changed the ExecutionContext over to use shared pointers for
the target, process, thread and frame since these objects can
easily go away at any time and any object that was holding onto
an ExecutionContext was running the risk of using a bad object.

Now that the shared pointers for target, process, thread and
frame are just a single pointer (they all use the instrusive
shared pointers) the execution context is much safer and still
the same size.

Made the shared pointers in the the ExecutionContext class protected
and made accessors for all of the various ways to get at the pointers,
references, and shared pointers.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140298 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Update declarations for all functions/methods that accept printf-style
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
166ba106f9d8c377f2fda72112c821550d2e82d1 01-Aug-2011 Sean Callanan <scallanan@apple.com> Added checking to make sure that the target has a
scratch AST context before attempting to parse.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136631 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
3058197753e56a7ea9f4c5784e460a3b977d7bd0 17-May-2011 Greg Clayton <gclayton@apple.com> Fixed the "mmap" to work on MacOSX/darwin by supplying the correct arguemnts.

Modified ClangUserExpression and ClangUtilityFunction to display the actual
error (if one is available) that made the JIT fail instead of a canned
response.

Fixed the restoring of all register values when the 'G' packet doesn't work
to use the correct data.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131454 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
c71899ef308e6134d1b0ca5f30cbc64414855e1a 18-Jan-2011 Greg Clayton <gclayton@apple.com> Thread safety changes in debugserver and also in the process GDB remote plugin.
I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123762 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp
6a92553d2cc2b7a3b853fcb6da101583435c2dc0 13-Jan-2011 Sean Callanan <scallanan@apple.com> Implemented a major overhaul of the way variables are handled
by LLDB. Instead of being materialized into the input structure
passed to the expression, variables are left in place and pointers
to them are materialzied into the structure. Variables not resident
in memory (notably, registers) get temporary memory regions allocated
for them.

Persistent variables are the most complex part of this, because they
are made in various ways and there are different expectations about
their lifetime. Persistent variables now have flags indicating their
status and what the expectations for longevity are. They can be
marked as residing in target memory permanently -- this is the
default for result variables from expressions entered on the command
line and for explicitly declared persistent variables (but more on
that below). Other result variables have their memory freed.

Some major improvements resulting from this include being able to
properly take the address of variables, better and cleaner support
for functions that return references, and cleaner C++ support in
general. One problem that remains is the problem of explicitly
declared persistent variables; I have not yet implemented the code
that makes references to them into indirect references, so currently
materialization and dematerialization of these variables is broken.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123371 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
aa301c49e8b31f01c551cffbaa74c8ba82851a79 03-Dec-2010 Sean Callanan <scallanan@apple.com> Fixed object lifetimes in ClangExpressionDeclMap
so that it is not referring to potentially stale
state during IR execution.

This was done by introducing modular state (like
ClangExpressionVariable) where groups of state
variables have well-defined lifetimes:

- m_parser_vars are specific to parsing, and only
exist between calls to WillParse() and DidParse().

- m_struct_vars survive for the entire execution
of the ClangExpressionDeclMap because they
provide the template for a materialized set of
expression variables.

- m_material_vars are specific to a single
instance of materialization, and only exist
between calls to Materialize() and
Dematerialize().

I also removed unnecessary references to long-
lived state that really didn't need to be referred
to at all, and also introduced several assert()s
that helped me diagnose a few bugs (fixed too).


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@120778 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
6a5aa8ab240a13f397e3e09f2ca1ea3f16b451c2 25-Sep-2010 Greg Clayton <gclayton@apple.com> Cleaned a few build related things up:

Added a virtual destructor to ClangUtilityFunction with a body to it cleans
itself up.

Moved our SharingPtr into the lldb_private namespace to keep it easy to make
an exports file that exports only what is needed ("lldb::*").



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114771 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
e8a59a8ec92e71203e434f28b5bac6606aacaf3c 13-Sep-2010 Sean Callanan <scallanan@apple.com> Bugfixes to the expression parser. Fixes include:

- If you put a semicolon at the end of an expression,
this no longer causes the expression parser to
error out. This was a two-part fix: first,
ClangExpressionDeclMap::Materialize now handles
an empty struct (such as when there is no return
value); second, ASTResultSynthesizer walks backward
from the end of the ASTs until it reaches something
that's not a NullStmt.

- ClangExpressionVariable now properly byte-swaps when
printing itself.

- ClangUtilityFunction now cleans up after itself when
it's done compiling itself.

- Utility functions can now use external functions just
like user expressions.

- If you end your expression with a statement that does
not return a value, the expression now runs correctly
anyway.

Also, added the beginnings of an Objective-C object
validator function, which is neither installed nor used
as yet.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113789 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
f18d91c9bbd01152b29d84ab55ad2f0bbc9baf6c 01-Sep-2010 Sean Callanan <scallanan@apple.com> Added support for dynamic sanity checking in
expressions. Values used by the expression are
checked by validation functions which cause the
program to crash if the values are unsafe.

Major changes:

- Added IRDynamicChecks.[ch], which contains the
core code related to this feature

- Modified CommandObjectExpression to install the
validator functions into the target process.

- Added an accessor to Process that gets/sets the
helper functions


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112690 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Expression/ClangUtilityFunction.cpp
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/source/Expression/ClangUtilityFunction.cpp