Making MightHaveChildren() always return true regardless for our own data formatters
This is meant to optimize performance for common most-often-not-empty container classes

llvm-svn: 169759

Change the wording of NSNumber summary from absurd value to unexpected value when a tagged pointer shows up that does not match our knowledge of the internals

llvm-svn: 169751

Replace printf with result.Printf, so that the plugin shows its output with any configuration of the LLDB I/O streams (esp. useful in graphic environments such as Xcode)

llvm-svn: 167030

Allow operating system plug-ins to specify the address for registers so we don't have to create data up front.

llvm-svn: 166701

Changing the NSDate data formatter to use GetData().uint64[] instead of relying on SBValue.GetValueAsUnsigned() to reinterpret a double as a uint64_t

llvm-svn: 166610

Adding the new has_children (or MightHaveChildren() in C++) for the existing synthetic children providers
In a few cases, the new call is going to be much more efficient than the previous num_children > 0 check
When the optimization was marginal (e.g. std::vector<>), the choice was to use num_children in order to keep
implementation details in one function instead of duplicating code

Next step is to provide test cases

llvm-svn: 166506

llvm-svn: 166443

Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:

settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py

Then run your program and see the extra threads. 

llvm-svn: 166244

Checking in fixes that I used to track down a leaking module. The heap module can now search the vm regions with the --vm-regions options to any of the heap functions. This is currently slow and often will time out when run on a large program since our user expression timeout is set to 500000 usec. We need to add an API to LLDB where we can specify the timeout for an expression.

llvm-svn: 165437

llvm-svn: 165341

This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface

There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.

Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command

For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands

Caveats:
	Currently, the new API objects and features are not exposed via Python.
	The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
	There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
	There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own

llvm-svn: 164865

llvm-svn: 164619

llvm-svn: 164192

<rdar://problem/11398693> Making sure we do not attempt to run code on zombie objects when attempting to format them

llvm-svn: 164156

llvm-svn: 164151

llvm-svn: 164149

Making sure to create the count attribute in synthetic children providers for libcxx at the right time

llvm-svn: 163823

llvm-svn: 163773

llvm-svn: 163675

Added some documentation and an accessor for the target with an explanation of why to not use "lldb.target".

llvm-svn: 163671

Added "heap" command to get info on all allocations on the heap. Currently only objective C objects are supported since they are easy to detect.

llvm-svn: 163637

llvm-svn: 163589

llvm-svn: 163543

Playing around with "objc_refs" over the weekend and improved it to work on a large ObjC program without running into expression timeouts. Now we get a full list of ObjC classes using a runtime function and then qsort the result. Also added code that can count all instances of each ObjC on the heap and also the total byte sizes for the object allocations.

llvm-svn: 163520

llvm-svn: 163441

llvm-svn: 163421

llvm-svn: 163162

llvm-svn: 163157

<rdar://problem/11485744> Implement important data formatters in C++. Have the Objective-C language runtime plugin expose class descriptors objects akin to the objc_runtime.py Pythonic implementation. Rewrite the data formatters for some core Cocoa classes in C++ instead of Python.

llvm-svn: 163155

superclasses on top of finding the exact class. The current attempt is still
too slow, but it lays the groundwork.

llvm-svn: 163135

Fixed an issue where not all text would always be seen when running any of the functions in heap.py in Xcode. Now we put the text directly into the command result object and skip STDIO since we have issues with STDIO right now in python scripts.

Also fixed an issue with the "--stack-history" option where MallocStackLoggingNoCompact was assumed to have to be enabled... It doesn't, just MallocStackLogging.

llvm-svn: 163042

llvm-svn: 163037

Added command lists that can be executed on launch, stop, crash and exit. Added code to auto import the lldb module that we can use on many stand alone modules.

llvm-svn: 162972

llvm-svn: 162967

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860

use re.findall and specify the regexp of regname: regvalue that we're interested in.
<rdar://problem/12188752> 

llvm-svn: 162806

llvm-svn: 162680

llvm-svn: 162540

llvm-svn: 162532

llvm-svn: 162531