Note: although it is now possible to declare blocks
and call them inside the same expression, we do not
generate correct block descriptors so these blocks
cannot be passed to functions like dispatch_async.

<rdar://problem/12578656>

llvm-svn: 178509

- process in 'unloaded' state was (incorrectly) considered to be alive by POSIX plugin
- above caused a regression in TestProcessLaunch cases

llvm-svn: 178493

- Check that process attach succeeded before attempting to WaitForProcessToStop (observed to cause hangs on Linux)
- Update comment in TestHelloWorld case -- attaching by name still broken

llvm-svn: 178491

To hook it up to individual test cases:
- define GetLongOptions() in your test case class to return something other than NULL (hopefully an array of options :-)
- implement ParseOption() to check for the short option char and do the right thing - return true at the end if you want more options to come your way or false if you don’t
- make sure that your Setup() call takes int& and char**& so that optind post-processing can happen - and call TestCase::Setup from your setup

llvm-svn: 178482

llvm-svn: 178477

they are probably trivial.  This means that we
don't confuse Clang about whether a class is
trivially copy constructible.  It can figure
that out itself as long as we don't explicitly
feed it the constructors.

If the class is trivially copy-constructible,
this can change the ABI that Clang uses to call
functions that return that class (e.g., by making
the object be returned in a register), so this
is quite important for correctness.

<rdar://problem/13457741>

llvm-svn: 178411

ASTContexts that will not stay around.  Before, we
did this in a very half-hearted way.  Now we maintain
work queues of all Decls that need to be completed
before the source ASTContext can go away; we then
expunge their origins completely.

<rdar://problem/13511875>

llvm-svn: 178410

manipulating the diagnostics engine.

<rdar://problem/13508470>

llvm-svn: 178399

(and using the new syntax for printing :-)

llvm-svn: 178389

Platform select documents a -S option but doesn't accept it, now it does.

llvm-svn: 178384

rdar://problem/13536544

llvm-svn: 178367

wasn't loaded into the underlying process or
couldn't be found.

<rdar://problem/13533671>

llvm-svn: 178363

llvm-svn: 178352

Enable tab completion for regular expression commands.

llvm-svn: 178348

<rdar://problem/13527167>

llvm-svn: 178325

“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.

<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>

llvm-svn: 178324

PC relative loads are missing disassembly comments when disassembled in a live process.

This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.

The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.

llvm-svn: 178315

llvm-svn: 178295

By default, omit the children for a char[] and just show the string contents
Can be overridden by appropriate command-line flags

llvm-svn: 178292

llvm-svn: 178265

Be sure to take the mutex when the destructor is called in case other threads are using these lists and those other threads have the mutex locked.

llvm-svn: 178262

Partial fix for the above radar.

Call ThreadList::Clear() in the ThreadList destructor so if any other threads currently have the thread list mutex, we won't destroy the list for them while they are using it. ThreadList::Clear() takes the mutex and clears the thread list contents.

llvm-svn: 178257

- Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable.

Thanks to Greg Clayton for his review feedback.

llvm-svn: 178252

llvm-svn: 178251

- All Linux logging channels now use a single global instance of lldb_private::Log, to handle the case of logging during process tear down.
- Also removed a single use of LogSP in FreeBSD and fixed a typo in a comment while reading through ProcessKDPLog.

Reviewed by Daniel Malea.

llvm-svn: 178242

- the ".app" would be treated as the app bundle final characters
and the SpringBoard launch would fail.
<rdar://problem/13258935> 

llvm-svn: 178209

Holding the Python lock while we call the Python C API to post-process objects returned from the OS plugins
This should avoid issues where some Python objects get invalidated while we are in the middle of processing them and we end up with an invalid Python state and a crash

llvm-svn: 178206

Protect against the case where the current inlined depth is wrong, and leads us to think we can't even get the
frame at index 0.  We should ALWAYS be able to get that.

<rdar://problem/13497571>

llvm-svn: 178205

llvm-svn: 178204

The other half of the checkin to produce better error messages when the ThreadPlanCallFunction isn't valid.

llvm-svn: 178203

<rdar://problem/13485541>

llvm-svn: 178202

llvm-svn: 178201

This test case was not doing the right thing with libc++ being used and was generating spurious over-completion warning flags

llvm-svn: 178192

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191

With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this:

{
auto lock = interpeter->AcquireInterpreterLock();
// do whatever you need to do...
} // lock will automatically be released here

This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions
Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-)

llvm-svn: 178189

- modified a comment

llvm-svn: 178178

Cleaned up some paths.

llvm-svn: 178177

llvm-svn: 178176

Enhance automated testing to include evaluating function calls.

llvm-svn: 178175

llvm-svn: 178154