llvm-svn: 149390

This commit provides a new default summary for Objective-C boolean variables, which shows YES or NO instead of the character value. A new category named objc is added to contain this summary provider. Any future Objective-C related formatters would probably fit here

llvm-svn: 149388

instances to not pthread_cancel the read threads and wreak havoc on the mutex
in our ConnectionFileDescriptor class.

Also cleaned up some shutdown delays.

llvm-svn: 149355

Fixed an issue where we can crash if you call cast when the SBValue
doesn't contain a valid value.

llvm-svn: 149345

llvm-svn: 149338

llvm-svn: 149297

llvm-svn: 149292

Also add test cases for watching a variable as well as a location expressed as an expression.

o TestMyFirstWatchpoint.py:

  Modified to test "watchpoint set -w write global".

o TestWatchLocationWithWatchSet.py:

  Added to test "watchpoint set -w write -x 1 g_char_ptr + 7" where a contrived example program
  with several threads is supposed to only access the array index within the range [0..6], but
  there's some misbehaving thread writing past the range.

rdar://problem/10701761

llvm-svn: 149280

Make BreakpointLocation::IsEnabled() consistent with the BreakpointLocation::SetEnabled() implementation.

llvm-svn: 149277

contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.

Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.

For any code the public API files, we should always be grabbing shared 
pointers to any objects for the current class, and any other classes prior
to running code with them.

llvm-svn: 149238

frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life 
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until 
the thread goes away or the StackID no longer exists in the stack for the 
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:

1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
    still around inside a shared pointer, yet, not part of the current 
    thread (a new stack frame object had appeared with the same stack ID and
    depth). 
    
We now avoid all such issues and properly keep up to date, or we start 
returning errors when the frame doesn't exist and always responds with
invalid answers.

Also fixed the UserSettingsController  (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer 
needed.

llvm-svn: 149231

all RTTI types, and since we don't use RTTI anymore since clang and llvm don't
we don't really need this header file. All shared pointer definitions have
been moved into "lldb-forward.h".

Defined std::tr1::weak_ptr definitions for all of the types that inherit from
enable_shared_from_this() in "lldb-forward.h" in preparation for thread
hardening our public API.

The first in the thread hardening check-ins. First we start with SBThread.
We have issues in our lldb::SB API right now where if you have one object
that is being used by two threads we have a race condition. Consider the
following code:

 1    int
 2    SBThread::SomeFunction()
 3    {
 4        int result = -1;
 5        if (m_opaque_sp)
 6        {
 7            result = m_opaque_sp->DoSomething();
 8        }
 9        return result;
10    }

And now this happens:

Thread 1 enters any SBThread function and checks its m_opaque_sp and is about
to execute the code on line 7 but hasn't yet
Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear()
and clears the contents of the shared pointer member
Thread 1 now crashes when it resumes.

The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a
lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this 
function would look like:

 1    int
 2    SBThread::SomeFunction()
 3    {
 4        int result = -1;
 5        ThreadSP thread_sp(m_opaque_wp.lock());
 6        if (thread_sp)
 7        {
 8            result = m_opaque_sp->DoSomething();
 9        }
10        return result;
11    }

Now we have a solid thread safe API where we get a local copy of our thread
shared pointer from our weak_ptr and then we are guaranteed it can't go away
during our function.

So lldb::SBThread has been thread hardened, more checkins to follow shortly.

llvm-svn: 149218

due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
pointer from just a pointer, which is also easily solved using the 
std::tr1::enable_shared_from_this class. 

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).

llvm-svn: 149207

from the SBTarget and SBModule interfaces. Also added many python properties
for easier access to many things from many SB objects.

llvm-svn: 149191

for when we enable the assisted layout.

llvm-svn: 149167

All of the commands now get globbed into a single line.

lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with
empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain
anything. 

llvm-svn: 149166

will ask ExternalASTSource objects to help laying out a type. This is needed
because the DWARF typically doesn't contain alignement or packing attribute
values, and we need to be able to match up types that the compiler uses
in expressions.

llvm-svn: 149160

Add an InstanceSettings::NotifyOwnerIsShuttingDown() method so that the owner can notify InstanceSettings instances
that their owner reference is no longer valid.

llvm-svn: 149145

test suite and I need to investigate this.

llvm-svn: 149141

llvm-svn: 149140

Emit the message about putting ' -- ' between the end of command options and the raw input conditionally,
that is, only if the command object does not want completion.  An example is the "settings set" command.

llvm-svn: 149139

memory by doing a swap.

Also added a few utilty functions that can be enabled for debugging issues
with modules staying around too long when external clients still have references
to them.

llvm-svn: 149138

watching for errors from pthread_mutex_destroy () (usually "Resource
busy" errors for when you have a mutex locked and try to destroy
it), and pthread_mutex_lock, and pthread_mutex_unlock (usually for
trying to lock an invalid mutex that might have possible already
been freed).

llvm-svn: 149135

ExecutionContext objects have shared pointers to Target, Process, Thread
and Frame objects and they can end up being held onto for too long.

llvm-svn: 149133

map that tracks all live Module classes. We must leak our mutex for our
collection class as it might be destroyed in an order we can't control.

llvm-svn: 149131

Fixed another double file descriptor close issue that could occur when destroying a ProcessGDBRemote() object. There was a race which was detected by our fd_interposing library:

error: /Applications/Xcode.app/Contents/MacOS/Xcode (pid=55222): close (fd=60) resulted in EBADF:
0   libFDInterposing.dylib              0x00000001082be8ca close$__interposed__ + 666
1   LLDB                                0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2   LLDB                                0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3   LLDB                                0x00000001194fe249 lldb_private::ConnectionFileDescriptor::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 835
4   LLDB                                0x00000001194fc320 lldb_private::Communication::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 634
5   LLDB                                0x000000011959c7f4 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 228
6   LLDB                                0x000000011959c6b5 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSeconds(StringExtractorGDBRemote&, unsigned int) + 49
7   LLDB                                0x0000000119629a71 GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse(ProcessGDBRemote*, char const*, unsigned long, StringExtractorGDBRemote&) + 509
8   LLDB                                0x00000001195a4076 ProcessGDBRemote::AsyncThread(void*) + 514
9   LLDB                                0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10  libsystem_c.dylib                   0x00007fff8ca028bf _pthread_start + 335
11  libsystem_c.dylib                   0x00007fff8ca05b75 thread_start + 13

fd=60 was previously closed with this event:
pid=55222: close (fd=60) => 0
0   libFDInterposing.dylib              0x00000001082be870 close$__interposed__ + 576
1   LLDB                                0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2   LLDB                                0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3   LLDB                                0x00000001194fbf00 lldb_private::Communication::Disconnect(lldb_private::Error*) + 92
4   LLDB                                0x00000001195a2a77 ProcessGDBRemote::StopAsyncThread() + 89
5   LLDB                                0x00000001195a2bf6 ProcessGDBRemote::DoDestroy() + 310
6   LLDB                                0x00000001195f938d lldb_private::Process::Destroy() + 85
7   LLDB                                0x0000000118819b48 lldb::SBProcess::Kill() + 72
8   DebuggerLLDB                        0x0000000117264358 DBGLLDBSessionThread(void*) + 4450
9   LLDB                                0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10  libsystem_c.dylib                   0x00007fff8ca028bf _pthread_start + 335
11  libsystem_c.dylib                   0x00007fff8ca05b75 thread_start + 13

fd=60 was created with this event:
pid=55222: socket (domain = 2, type = 1, protocol = 6) => fd=60
0   libFDInterposing.dylib              0x00000001082bc968 socket$__interposed__ + 600
1   LLDB                                0x00000001194fd75f lldb_private::ConnectionFileDescriptor::ConnectTCP(char const*, lldb_private::Error*) + 179
.....

llvm-svn: 149103

Remove a pseudo terminal master open and slave file descriptor that was being
used for pythong stdin. It was not hooked up correctly and was causing file
descriptor leaks.

llvm-svn: 149098

target variable -f <format> [args]
frame variable -f <format> [args]
expression -f <format> -- expr

llvm-svn: 149080

llvm-svn: 149002

llvm-svn: 148994

llvm-svn: 148876

an error along with its boolean result.  The
expression parser reports this error if the 
interpreter fails and the expression could not be
run in the target.

llvm-svn: 148870

llvm-svn: 148756

llvm-svn: 148743

where we changed the CommandObjectSettingsSet object impl to require raw command string.

Do the same for CommandObjectSettingsAppend/InsertBefore/InsertAfter classes and
add test cases for basic functionalities as well as for variable name completion.

llvm-svn: 148719

A Small tweak to handle a zero timeout.

llvm-svn: 148617

we didn't implement that in setting the socket option.
<rdar://problem/10711649>

llvm-svn: 148616

where we changed the CommandObjectSettingsSet object impl to require raw command string.

Do the same for CommandObjectSettingsReplace class and add two test cases; one for
the "settings replace" command and the other to ensure that completion for variable
name still works. 

llvm-svn: 148615

Release more stuff in Process::Destroy().

llvm-svn: 148597

  Fix a bug where "settings set -r th" wouldn't complete.

o UserSettingsController.cpp:

  Fix a bug where "settings set target.process." wouldn't complete.

o test/functionalities/completion:

  Add various completion test cases related to 'settings set' command.

llvm-svn: 148596