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

llvm-svn: 179110

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

/Volumes/KernelDebugKit (the default mount point for the Kernel Debug
Kit dmgs).

llvm-svn: 179058

to 'off' for a week or so while we test the behavior in different environments.

llvm-svn: 178951

Don't call DisableBreakpointSite (i.e. don't try to remove the breakpoint from the target process) if the target
process is no longer alive.

<rdar://problem/13320991>

llvm-svn: 178936

Now we can:
1 - see the return value for functions that return types that use the "ext_vector_size"
2 - dump values that use the vector attributes ("expr $ymm0")
3 - modified the DWARF parser to correctly parse GNU vector types from the DWARF by turning them into clang::Type::ExtVector types instead of just standard arrays

llvm-svn: 178924

platform.plugin.darwin-kernel.kext-directories
platform.plugin.darwin-kernel.search-locally-for-kexts

and fix a few FileSpec handling issues for the kext-directories setting.

llvm-svn: 178920

Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.

llvm-svn: 178897

llvm-svn: 178889

Add two initial settings for the PlatformDarwinKernel plugin,

plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]

llvm-svn: 178846

from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)

Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.

llvm-svn: 178836

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

plugin will index the kext bundles on the local filesystem when
created.  During a kernel debug session, when the DynamicLoader
plugin needs to locate a kext by name like
"com.apple.com.apple.filesystems.autofs", the Platform can quickly
look for a UUID match in those kernel debug kit directories it
previously indexed.

I'm still working on profiling the performance impact of the inital
kext bundle scan; there will likely need to be a switch to enable
or disable this plugin's scan.

This only affects Mac kernel debugging and the code is only built
on Apple systems because of some use of low-level CoreFoundation
to parse plists.

<rdar://problem/13503583> 

llvm-svn: 178827

Show thread name and dispatch queue by default in the thread display.

llvm-svn: 178790

LLDB now can use a single dash for all long options for all commands form the command line and from the command interpreter. This involved just switching all calls from getopt_long() to getopt_long_only().

llvm-svn: 178789

so it can be re-entered while iterating over a directory safely.

llvm-svn: 178738

children - which it may have to compute.  Thus it needs to take the API lock.

<rdar://problem/13560869>

llvm-svn: 178734

<rdar://problem/11319574>

llvm-svn: 178732

The __NSArrayI synthetic children provider was running expressions to generate children, which is inefficient for large amounts of data
Reimplementing to use a faster algorithm

llvm-svn: 178729

Changes to lldb made the following fail when it used to work:

% cd /tmp
% lldb ls
error: unable to find executable for '/tmp/ls'

Resolving an executable with no relative path was broken, now its fixed.

llvm-svn: 178719

llvm-svn: 178718