which can conflict with accurate crash reporting
in multithreaded contexts.

llvm-svn: 163282

Fixed an issue where we didn't parse N_SO stab pairs where the first N_SO was a relative path.

llvm-svn: 163259

llvm-svn: 163250

When the vendor and OS are not specified in a triple, only let unspecified vendor and OS fields matchs for the current host platform.

llvm-svn: 163248

llvm-svn: 163246

llvm-svn: 163245

Move calculating the CurrentInlinedDepth to AFTER the synchronous breakpoint callback gets a chance to run.
If the stopped event comes in with the Restarted bit set, don't try to hand that to the plans, but just return ShouldStop = false.  There's nothing useful the plans can do, since the target is already running.

llvm-svn: 163244

Implementing an Options class for EvaluateExpression() in order to make the signature more compact and make it easy to 'just run an expression'

llvm-svn: 163239

Don't crash when we can't resolve our stub to a symbol.

llvm-svn: 163189

llvm-svn: 163183

llvm-svn: 163170

Modified patch from Matt Kopec that fixes a process launch issue on linux where we wouldn't acquire the process run lock.

llvm-svn: 163163

llvm-svn: 163162

llvm-svn: 163157

llvm-svn: 163156

<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

Patch from Filipe Cabecinhas that uses argparse in dotest.py instead of a hand coded option. I made a few modifications:

Changed the '-A' option to also have a long option of '--arch'. This is now specified multiple times to get multiple architectures.

Old: -A i386^x86_64
New: -A i386 -A x86_64
     --arch i386 --arch x86_64
     
Changed the '-C' option to also have a long option of '--compiler'. This is now specified multiple times to get multiple compiler.

Old: -C clang^gcc
New: -C clang -C gcc
     --compiler clang --compiler gcc
llvm-svn: 163141

Patch from info from Daniel Malea that should fix the build on linux after fixes committed with revision 162860.

llvm-svn: 163139

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

llvm-svn: 163135

Initial check-in of "fancy" inlined stepping.  Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true.  With that
on, basic inlined stepping works, including step-over of inlined functions.  But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately.  So for now its off.

llvm-svn: 163044

Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt.

Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function).

llvm-svn: 163043

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

Add a convenience function to get the range containing a given PC specified as load address + Target.

llvm-svn: 163038

llvm-svn: 163037

Added a fix for incorrect dynamic typing. Before when asking if a C++ class could be dynamic, we would answer yes for incomplete C++ classes. This turned out to have issues where if a class was not virtual, yet had its first ivar be an instance of a virtual class, we would incorrectly say that a class was virtual and we would downcast it to be a pointer to the first ivar. We now ask the class to complete itself prior to answering the question. We need to test the effects on memory of this change prior to submission. It is the safest and best fix, but it does have a potential downside of higher memory consumption.

llvm-svn: 163014

llvm-svn: 163011

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

./verify_api.py --library ./LLDB.framework/LLDB --api-regex lldb --arch x86_64 /Applications/Xcode.app/Contents/PlugIns/DebuggerLLDB.ideplugin/Contents/MacOS/DebuggerLLDB

So you specify a library with the "--library" option, then you specify an API regular expression that you want to match the executables against with "--api-regex <regex>", here we specify "lldb" to catch all undefined external API functions from the binary we want to test, then we specify the architectures to check with "--arch <arch>" (this can be specified more than once), and you give one or more executables.

llvm-svn: 162941

OptionValueFileSpec had an accessor to read the contents of the file and return the data. This can end up being used to get the string contents of a text file and could end up not being NULL terminated. I added accessors to get the file contents raw, or with a null terminator. Added the needed calls to make this happen in the FileSpec and File classes.

llvm-svn: 162921

ModuleList::GetSharedModule() returned NULL.

<rdar://problem/12182971>

llvm-svn: 162871

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

Fix a subtle ArchSpec::cores_match() logic issue which prevents the add-dsym command
to add a debug symbol file to one of the target's current modules.

llvm-svn: 162802

llvm-svn: 162795

llvm-svn: 162794

llvm-svn: 162756

llvm-svn: 162753

llvm-svn: 162685

llvm-svn: 162680