- older versions of clang are unable to include <chrono> from libstdc++
- skipping tests until buildbots are updated

llvm-svn: 181829

- test_breakpoint_callback -- filed llvm.org/pr-16000
- test_listener_resume -- resume a process from a thread waiting on SBListener
- test_listener_event_description -- SBEvent description from SBListener thread
- test_listener_event_process -- query process/thread/stack info from SBListener thread

llvm-svn: 181819

llvm-svn: 181818

The "lldb" driver was interfering with STDOUT and STDERR if the output was over 1024 charcters long. The output was grabbing 1024 characters at a time, before it output the characters, it was writing characters to the screen to clear the current line. This has been fixed.

I also fixed the command interpreter from mixing the "(lldb) " prompt in with program output by always manually checking for program output. This was done by having the command interpreter know when it is in the middle of executing a command by setting a bool. This was needed since sometimes when a command would run the target, like with a command like 'expression (int)printf("hello\n")', the process would push a new input reader, and then pop it when it was done. This popping of the input reader would cause the command interpreter to get sent a reactivated message (from the private process state thread) and cause it to ask for another command, even though we were still in the middle of the command ('expression (int)printf("hello\n")'). Now we set a bool to true, run the command and set the bool to false. If we get reactivated while we are in the middle of a command, we don't say we are ready for a new command. This coupled with emitting the STDOUT/STDERR first after each command, followed by the command results, followed by then saying we are ready for a new command, should help cleanup the command line output on all platforms.

llvm-svn: 181807

Fix inline stepping test case on Linux because Thread::ThreadStoppedForAReason ignored virtual steps.
- add IsVirtualStep() virtual function to ThreadPlan, and implement it for
  ThreadPlanStepInRange
- make GetPrivateStopReason query the current thread plan for a virtual stop to
  decide if the current stop reason needs to be preserved
- remove extra check for an existing process in GetPrivateStopReason

llvm-svn: 181795

llvm-svn: 181789

Most importantly, have DoReadGPR/DoReadFPU/DoReadEXC return -1
to indicate failure if they're called.  Else these could override
the Error setting for the relevant thread state -- if the core file
didn't include a floating point thread state, for instance, these
functions would clear the Error setting for that register set and 
lldb would display random bytes as those registers' contents.
<rdar://problem/13665075> 

llvm-svn: 181757

in one large block - and be sure toget the fpscr value as well when
processing a core file.

llvm-svn: 181756

of arm Mach-O core files.
<rdar://problem/13665075>

llvm-svn: 181755

llvm-svn: 181742

llvm-svn: 181741

llvm-svn: 181739

- Also refactors TestRegisters.py because test_convenience_registers_with_process_attach now fails with an assert.

TODO: Cross-reference the skipOnLinux decorator with a bugzilla report after root-causing this issue.
llvm-svn: 181737

- should fix automatic tests set up on http://llvm-jenkins.debian.net
- needed in order to make Debian package builds depend on passing test suite

llvm-svn: 181736

llvm-svn: 181735

- Also improved test coverage for passing tests to include expr/x
and a sanity check for $eax as the lower half of $rax.

llvm-svn: 181727

- added missing ConstString header
- moved "using lldb*" statements to OS-independent section

llvm-svn: 181724

Patch by Mike Sartain.

llvm-svn: 181722

LLDB transition page.  Also fixed a <b>...</b>
tag.

<rdar://problem/13871874>

llvm-svn: 181720

Unblock linux builds. The real fix for this is tracked by the above radar, but this temporary hack should fix things for now.

llvm-svn: 181717

llvm-svn: 181712

llvm-svn: 181711

Provide a mechanism through which users can disable loading the Python scripts from dSYM files
This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script")
You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load

llvm-svn: 181709

Also pass the MCRegInfo to createMCAsmInfo. Follow the modification introduced in commit r181680 of llvm

llvm-svn: 181703

llvm-svn: 181695

Add a new constructor with ConstString (and not only const char *). Hopefully fixes the build of lldb

llvm-svn: 181694

names when specifying the DynamicLoaderDarwinKernel.

ProcessGDBRemote wasn't setting the dyld string any more; remove
the remaining code tracking the dyld plugin name altogether from
that process plugin.

llvm-svn: 181658

Don't want about being unable to find a needed objective-c runtime
function when we're core file debugging and can't jit anything
anyway.  Don't warn when quitting a debug session on a core file,
the program state can be reconstructed by re-running lldb on the
same core file again.

llvm-svn: 181653

Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state.

llvm-svn: 181651

Use mangled and demangled names when checking for a function in a namespace and a function in an anonymous namespace, respectively.

llvm-svn: 181645

passed to breakpoints.

<rdar://problem/13853205>

llvm-svn: 181636

<rdar://problem/13594769>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:

Changed:

virtual const char * GetPluginName() = 0;

To: 

virtual ConstString GetPluginName() = 0;

Removed:

virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. 
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.

llvm-svn: 181631

llvm-svn: 181613

This re-submission of this patch fixes a problem where the code sometimes caused a deadlock.  The Process::SetPrivateState method was locking the Process::m_private_state variable and then later calling ThreadList::DidStop, which locks the ThreadList mutex.  Other methods in ThreadList which were being called from other threads lock the ThreadList mutex and then call Process::GetPrivateState which locks the Process::m_private_state mutex.  To avoid deadlocks, Process::SetPrivateState now locks the ThreadList mutex before locking the Process::m_private_state mutex.

llvm-svn: 181609

Removed expectedFailureDarwin, and added a note about the disparity between the automated tests and testing at the lldb command-line.

llvm-svn: 181602

Added an integration test to step through a crash and then test for globals, locals, arguments, registers and the back-trace.

llvm-svn: 181599

llvm-svn: 181582

I'll revisit this and apply once I figure out how to address that.

llvm-svn: 181581

starting a kdp communication session, instead of assuming darwin
kernel for any "non-EFI" kdp session.
<rdar://problem/13854098>

llvm-svn: 181566

into a CXXRecordDecl on the ground; rather, put
them into the translation unit as functions.

<rdar://problem/13834404>

llvm-svn: 181560