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

llvm-svn: 179643

ShouldStop on the threads, which might destroy information needed to correctly compute another 
thread's StopInfo.

<rdar://problem/13664026>

llvm-svn: 179641

differs from lldb's own shared cache, and where the inferior process shared
cache does not match up with the on-disk shared cache file.

Simplify the code where lldb gets its own shared cache uuid a little bit.

llvm-svn: 179633

llvm-svn: 179623

Special handling for file descriptor connections that are tty files.

llvm-svn: 179613

Show an error message when we have a corrupt mach-o file where the LC_SEGMENT or LC_SEGMENT_64 load command have file offsets or file offsets + sizes that extend beyond the end of the file.

llvm-svn: 179605

DynamicLoaderMacOSXDYLD::ReadAllImageInfosStructure for
version 13 of that structure.

llvm-svn: 179584

a UUID for the shared cache libraries that can be used to confirm
that one process' shared cache is the same as another, or that a
process' in-memory shared cache is a match for a given on-disk
dyld_shared_cache binary file.  Use these UUIDs to catch some
uncommon problems when the shared caches are being changed for debug
purposes.
<rdar://problem/13524467>

llvm-svn: 179583

No code changes in this checkin, only whitespace.

llvm-svn: 179579

llvm-svn: 179577

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

- Do not add symbols with no names
- Make sure that symbols from ELF symbol tables know that the byte size is correct. Previously the symbols would calculate their sizes by looking for the next symbol and take symbols that had zero size and make them have invalid sizes.
- Added the ability to dump raw ELF symbols by adding a Dump method to ELFSymbol

Also removed some unused code from lldb_private::Symtab.

llvm-svn: 179466

Materializer.

llvm-svn: 179445

Materializer use that API when dematerializing
variables.

llvm-svn: 179443

lets a ValueObject's contents be set from raw
data.  This has certain limitations (notably,
registers can only be set to data that is as
large as the register) but will be useful for
the new Materializer.

I also exposed this interface through SBValue.
I have added a testcase that exercises various
special cases of SBValue::SetData().

llvm-svn: 179437

defines a Return Address register (e.g. lr on arm) but the RA register
hasn't been saved anywhere yet -- it is still in a live reg.
<rdar://problem/13503130> 

llvm-svn: 179431

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

Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread. 
- Cleaned up all the places where a thread inside a thread was causing problems

llvm-svn: 179405

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

llvm-svn: 179390

settings set platform.plugin.darwin-kernel.search-locally-for-kexts true

llvm-svn: 179348

Save away the locations at the site we hit and iterate over that collection.  Otherwise the action of one location
could delete the other locations, and that would leave us iterating over a reduced size collection and crash.

<rdar://problem/13592544>

llvm-svn: 179332

This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
	int value;
	node* child;
	node (int x)
	{
		value = x;
		child = nullptr;
	}
};

int main ()
{
	node root(1);
	node* ptr = &root;
	int j = 2;
	while (1)
	{
		ptr->child = new node(j++);
		ptr = ptr->child;
	}
	return 0;
}

the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it

This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.

llvm-svn: 179330

Fixed a case there the OperatingSystemPython would try to access and play with SBValue objects when the process' public run lock was taken. Prior to this fix, all attempts to run any SBValue functions would fail if run from the private state thread (like updating the thread list). Now we have two run locks, one for public (all threads except the private state thread) and one for private.

llvm-svn: 179329

llvm-svn: 179326

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

Static variables inside classes were not being added to the RecordDecl, now they are. This gets us closer to being able to display static variables in classes.

llvm-svn: 179296

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

to '-A'.

Add option '-a' / '--address' to disassemble which will find the
function that contains that address, and disassemble the entire function.

<rdar://problem/13436207> 

llvm-svn: 179258

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

SectionList so we don't try to do anything with this file.  Currently we end up crashing
later in the debug session when we read past the end of the file -- this at least gets us
closer with something like ProcessMachCore printing "error: core file has no sections".
<rdar://problem/13468295>

llvm-svn: 179152

if we didn't want to put in a CXXConstructorDecl.  This
prevents malformed classes (i.e., classes with regular C
functions as members) from being generated from type
information (and fixes a crash in the test suite).

<rdar://problem/13550765>

llvm-svn: 179136

Fix the help for unwind-on-error, it no longer controls what happens when an expression hits a breakpoint.

llvm-svn: 179133

doesn't have a corresponding type.

<rdar://problem/13596142>

llvm-svn: 179130