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

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

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

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

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

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

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

llvm-svn: 149080

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

  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

<rdar://problem/10719481>

llvm-svn: 148494

where we grabbed the variable list size from the wrong list (we needed it
from "args" and we were getting it from "variable_list_sp").

llvm-svn: 148425

Fixed two double "int close(int fd)" issues found by our file descriptor
interposing library on darwin:

The first is in SBDebugger::SetInputFileHandle (FILE *file, bool transfer_ownership)
where we would give our FILE * to a lldb_private::File object member variable and tell
it that it owned the file descriptor if "transfer_ownership" was true, and then we
would also give it to the communication plug-in that waits for stdin to come in and
tell it that it owned the FILE *. They would both try and close the file.

The seconds was when we use a file descriptor through ConnectionFileDescriptor 
where someone else is creating a connection with ConnectionFileDescriptor and a URL
like: "fd://123". We were always taking ownwership of the fd 123, when we shouldn't
be. There is a TODO in the comments that says we should allow URL options to be passed
to be able to specify this later (something like: "fd://123?transer_ownership=1"), but
we can get to this later.

llvm-svn: 148201

When the lldb_private::Debugger goes away, it should cleanup all
of its targets.

llvm-svn: 148189

name + arguments when the data is available. It seems to work really well, 
but some more testing is needed before we make this on by default.

The new function format name is:

 ${function.name-with-args}

To see how to use these formats see the website:

    http://lldb.llvm.org/formats.html

Here is a sample backtrace of debugging LLDB with LLDB using this new format
value:

(lldb) thread backtrace all
* thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread
    frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10
    frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840
    frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92
    frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317
    frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388
    frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436
    frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181
    frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325
    frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460
    frame #9: 0x0000000100000d54 lldb start + 52

  thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input>
    frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
    frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542
    frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273
    frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317
    frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344
    frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549
    frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
    frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13

  thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline>
    frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
    frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542
    frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273
    frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317
    frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344
    frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549
    frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
    frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13

  thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output>
    frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10
    frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542
    frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273
    frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317
    frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344
    frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549
    frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
    frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13

  thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io>
    frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10
    frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247
    frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155
    frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578
    frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37
    frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311
    frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391
    frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345
    frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549
    frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335
    frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13
(lldb) 

llvm-svn: 148110

llvm-svn: 148057

and doing it both at the ModuleList and Module levels means we look 4 times for a negative
search.  Also, don't do the search for the stripped name if that is the same as the original
one.

llvm-svn: 148054

mmap() the entire object file contents into memory with MAP_PRIVATE.
We do this because object file contents can change on us and currently
this helps alleviate this situation. It also make the code for accessing
object file data much easier to manage and we don't end up opening the
file, reading some data and closing the file over and over.

llvm-svn: 148017

and also print out the full path and architecture.

llvm-svn: 147908

to fix the issues we run into on darwin even though the docs don't
seems to say it will.

llvm-svn: 147835

The previous approach to controlling the recursion was doing it from
outside the function which is not reliable. Now it is being done inside
the function. This might not solve all of the crashes that we were seeing
since there are other functions that clear the bit that indicates that
the summary is in the process of being generated, but it might solve some.

llvm-svn: 147741

Fixed a crasher when trying to load an expression prefix file:

% touch /tmp/carp.txt
% xcrun lldb
(lldb) settings set target.expr-prefix /tmp/carp.txt
Segmentation fault

llvm-svn: 147646

Removed an extra call to close that was causing problems and also
now use the Host::File class to open the file.

llvm-svn: 147638

so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.

For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.

llvm-svn: 147596

result variable on a "finish" statement.  The
ownership of the result value was not being properly
assigned to the newly-created persistent result
variable; now it is.

llvm-svn: 147587

Be better at detecting when DWARF changes and handle this more
gracefully than asserting and exiting.

Also fixed up a bunch of system calls that weren't properly checking
for EINTR.

llvm-svn: 147559

eFormatCString is specified, I have made
DataExtractor::Dump properly escape the string.
This prevents LLDB from printing characters
that confuse terminals.

llvm-svn: 147536

Watch for empty symbol tables by doing a lot more error checking on
all mach-o symbol table load command values and data that is obtained.
This avoids a crash that was happening when there was no string table.

llvm-svn: 147358

Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to
work for bitfields.

llvm-svn: 147332

Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.

llvm-svn: 147157

llvm-svn: 147149

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBDebugger APIs.

llvm-svn: 146917

as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers.  That way this will always
be good.

llvm-svn: 146806

valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider

Patch from Enrico Granata:

The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.

The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.

llvm-svn: 146768

handles.

llvm-svn: 146746

clients to disassemble a series of raw bytes as
demonstrated by a new testcase.

In the future, this API will also allow clients
to provide a callback that adds comments for
addresses in the disassembly.

I also modified the SWIG harness to ensure that
Python ByteArrays work as well as strings as
sources of raw data.

llvm-svn: 146611