When specifying a relative path for the --framework option to dotest.py, Python would end up being confused and unable to locate the embedded_interpreter module, causing every testcase that uses the Script Interpreter (e.g. functionalities/data-formatter/data-formatter-stl/libstdcpp) to fail without even trying
This checkin fixes that problem by absolutizing the path before pushing it to the sys.path

llvm-svn: 179341

This makes the dynamic values test case work for both libc++ and libstdcpp

llvm-svn: 179333

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: 179328

Fixed SBValueList to have a __str__ function like all other SB classes. Previously this was done as __repr__.

llvm-svn: 179327

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

Moving over to source-regex might be a good idea, but it’s not what we really want to test. Ideally, we would set a regex breakpoint to find the right line, then delete it and set one by file and line with the right line info from before.

llvm-svn: 179246

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

re-fetch the value.

llvm-svn: 178962

llvm-svn: 178955

llvm-svn: 178954

if we have an updated task_info call available; else fall back to getting
the default host-wide page size.

Update all uses of the vm page size to get it via MachVMMemory::PageSize().

<rdar://problem/13477763>, <rdar://problem/13498504> 

llvm-svn: 178953

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

llvm-svn: 178830

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

crashlog.py was always subtracting 1 to point to the previous instruction when symbolicating ARM backtraces. Many times the backtraces will include bit zero set to 1 to indicate thumb, so we need to make sure we mask the address and then backup one for non frame zero frames.

llvm-svn: 178812

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

llvm-svn: 178790