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

the Objective-C object checker and the pointer
checker) were not always installed into expressions.

<rdar://problem/13882566>

llvm-svn: 182183

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

regions that aren't actually allocated in the
process.  This cache is used by the expression
parser if the underlying process doesn't support
memory allocation, to avoid needless repeated
searches for unused address ranges.

Also fixed a silly bug in IRMemoryMap where it
would continue searching even after it found a
valid region.

<rdar://problem/13866629>

llvm-svn: 182028

llvm-svn: 181911

to the DeclContext.  This fulfils the contract that
we make with Clang by returning ELR_AlreadyLoaded.

This is a little aggressive in that it does not allow
the ASTImporter to import the child decls with any
lexical parent other than the Decl that reported them
as children.

<rdar://problem/13517713>

llvm-svn: 181498

in the underlying llvm::JITMemoryManager API.

llvm-svn: 181387

support operands with vector types, it now reports
that it cannot interpret expressions that use
vector types.  They get sent to the JIT instead.

<rdar://problem/13733651>

llvm-svn: 180899

give up if it couldn't find the address for the
first symbol it found with a particular name and
type.

<rdar://problem/13748253>

llvm-svn: 180764

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

null pointer.

<rdar://problem/13745684>

llvm-svn: 180663

presence of malformed class types.

<rdar://problem/13740646>

llvm-svn: 180645

This fixes a problem on Linux where allocated memory would get overun in some use cases (ie. in TestExprs2.py).

llvm-svn: 180614

interpreter.  They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.

Also updated the #includes for IRInterpreter
accordingly.

llvm-svn: 180565

disabled.

llvm-svn: 180563

Don't crash if we try to interpret the IR (incorrectly in this case) and can't handle the size. This came from trying to do:

(lldb) p typedef float __attribute__((ext_vector_type(8))) __ext_vector_float8; (__ext_vector_float8)$ymm0

llvm-svn: 180235

sent to "super".

<rdar://problem/13042260>

llvm-svn: 180217

<rdar://problem/12977827>

llvm-svn: 180215

not find multiple functions with the same name but
different types.  Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.

Also added a test case.

<rdar://problem/11367837>

llvm-svn: 180167

Be sure to print out the fully mangled name when we are unable to find a function to call so we can easily look for this symbol if needed.

llvm-svn: 180151

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

llvm-svn: 179918

llvm-svn: 179892

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

an Allocation to reduce heap fragmentation and
make the code less brittle (and to make some
buildbots happier).

llvm-svn: 179868

now that the IR interpreter and the JIT share the same
materialization codepaths.

llvm-svn: 179842

Previously, the options for a breakopint or its
locations stored only the text of the breakpoint
condition (ironically, they used ClangUserExpression
as a glorified std::string) and, each time the condition
had to be evaluated in the StopInfo code, the expression
parser would be invoked via a static method to parse and
then execute the expression.

I made several changes here:

  - Each breakpoint location now has its own
    ClangUserExpressionSP containing a version of
    the breakpoint expression compiled for that exact
    location.

  - Whenever the breakpoint is hit, the breakpoint
    condition expression is simply re-run to determine
    whether to stop.

  - If the process changes (e.g., it's re-run) or
    the source code of the expression changes (we use
    a hash so as to avoid doing string comparisons)
    the ClangUserExpressionSP is re-generated.

This should improve performance of breakpoint
conditions significantly, and takes advantage of
the recent expression re-use work.

llvm-svn: 179838

parser.

llvm-svn: 179832

and made attempts to allocate memory in the process
fall back to FindSpace and just allocate memory on
the host (but with real-looking pointers, hence
FindSpace) if the process doesn't allow allocation.
This allows expressions to run on processes that don't
support allocation, like core files.

This introduces an extremely rare potential problem:
If all of the following are true:

- The Process doesn't support allocation;

- the user writes an expression that refers to an
  address that does not yet map to anything, or is
  dynamically generated (e.g., the result of calling
  a function); and

- the randomly-selected address for the static data
  for that specific expression runs into the
  address the user was expecting to work with;

then dereferencing the pointer later results
in the user seeing something unexpected.  This is
unlikely but possible; as a future piece of work,
we should have processes be able to hint to the
expression parser where it can allocate temporary data
of this kind.

llvm-svn: 179827

llvm-svn: 179810

After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.

llvm-svn: 179805

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

llvm-svn: 179799

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.

llvm-svn: 179779

will be gone soon!) that lets it interpret a function
using just an llvm::Module, an llvm::Function, and a
MemoryMap.

Also added an API to IRExecutionUnit to get at its
llvm::Function, so that the IRInterpreter can work
with it.

llvm-svn: 179704

it doesn't actually hold any important state.

llvm-svn: 179702

a ClangExpressionDeclMap.  Any functions that
require value resolution etc. fail if the
ClangExpressionDeclMap isn't present - which is
exactly what is desired.

llvm-svn: 179695

IRMemoryMap rather than through its own memory
abstraction.  This considerably simplifies the
code, and makes it possible to run the
IRInterpreter multiple times on an already-parsed
expression in the absence of a ClangExpressionDeclMap.

Changes include:

  - ClangExpressionDeclMap's interface methods
    for the IRInterpreter now take IRMemoryMap
    arguments.  They are not long for this world,
    however, since the IRInterpreter will soon be
    working with materialized variables.

  - As mentioned above, removed the Memory class
    from the IR interpreter altogether.  It had a
    few functions that remain useful, such as
    keeping track of Values that have been placed
    in memory, so I moved those into methods on
    InterpreterStackFrame.

  - Changed IRInterpreter to work with lldb::addr_t
    rather than Memory::Region as its primary
    currency.

  - Fixed a bug in the IRMemoryMap where it did not
    report correct address byte size and byte order
    if no process was present, because it was using
    Target::GetDefaultArchitecture() rather than
    Target::GetArchitecture().

  - Made IRMemoryMap methods clear the Errors they
    receive before running.  Having to do this by
    hand is just annoying.

The testsuite seems happy with these changes, but
please let me know if you see problems (especially
in use cases without a process).

llvm-svn: 179675

It doesn't use it yet; the next step is to make it
use the IRMemoryMap instead of its own conjured-up
Memory class.

llvm-svn: 179650

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