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

to make debugging easier when things go wrong.

llvm-svn: 179576

- If an allocation is mirrored between the host
  and the process, update the host's version
  before returning a DataExtractor pointing to
  it.

- If anyone attempts to access memory in a
  process/target that does not have a corresponding
  allocation, try accessing the memory directly
  before erroring out.

llvm-svn: 179561

Also improved logging and error handling in a few
spots in the Materializer.

llvm-svn: 179557

that it works in the absence of a process.  Codepaths
in the Materializer now use the best execution context
scope available to them.

llvm-svn: 179539

Materializer.

llvm-svn: 179445

Materializer use that API when dematerializing
variables.

llvm-svn: 179443

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.

llvm-svn: 179416

variables in the Materializer.  We don't use this
code yet, but will soon once the other materializers
are online.

llvm-svn: 179390

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.

llvm-svn: 179318

parser.

<rdar://problem/13631469>

llvm-svn: 179304

Example:
CMake Error at cmake/modules/LLVMProcessSources.cmake:89 (message):
  Found unknown source file
  /llvm-toolchain-3.3~svn179293.cmake/tools/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp

llvm-svn: 179295

entities with the new Materializer so that it only
registers those entities that actually need to be
placed in the struct.

llvm-svn: 179253

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.

llvm-svn: 179245

doesn't have a corresponding type.

<rdar://problem/13596142>

llvm-svn: 179130

behalf of the JIT.  We don't need it to be writable
since we are using special APIs to write into it.

<rdar://problem/13599185>

llvm-svn: 179077

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.

llvm-svn: 178832

This should fix the build breakage caused by the api change in 178663.

llvm-svn: 178700

Symbol table function names should support lookups like symbols with debug info. 

To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.

llvm-svn: 178608

Note: although it is now possible to declare blocks
and call them inside the same expression, we do not
generate correct block descriptors so these blocks
cannot be passed to functions like dispatch_async.

<rdar://problem/12578656>

llvm-svn: 178509

manipulating the diagnostics engine.

<rdar://problem/13508470>

llvm-svn: 178399

PC relative loads are missing disassembly comments when disassembled in a live process.

This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.

The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.

llvm-svn: 178315

llvm-svn: 178204

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.

llvm-svn: 178191

LLDB to crash.

<rdar://problem/13497915>

llvm-svn: 178115

Don't use a "uintptr_t" for the metadata key, use a "void *".  This removes all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata.

llvm-svn: 178113

went wrong and we tried to get layout information
that wasn't there.

<rdar://problem/13490170>

llvm-svn: 177880