whether we try to call an external program to load symbols unconditionally,
or if we check the user's preferences before calling it.

ProcessMachCore now sets CanJIT to false - we can't execute code in a core file.

DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule changed
to load the kernel from an on-disk file if at all possible.
Don't load the kext binaries out of memory from the remote systems - their linkedit doesn't
seem to be in a good state and we'll error out down in SymbolVendorMacOSX if we try to use
the in-memory images.
Call Symbols::DownloadObjectAndSymbolFile to get the kext/kernel binary -- the external
program may be able to give us a file path on the local filesystem instead of reading
the binary / dSYM over a network drive every time.  Fall back to calling 
Target::GetSharedModule() like before if DownloadObjectAndSymbolFile fails.

llvm-svn: 165471

llvm-svn: 165460

llvm-svn: 165441

Added a new "module" log channel which covers module creation, deletion, and common module list actions.

Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line.

This was used to track down the leaking module issue I fixed last week.

llvm-svn: 165438

Checking in fixes that I used to track down a leaking module. The heap module can now search the vm regions with the --vm-regions options to any of the heap functions. This is currently slow and often will time out when run on a large program since our user expression timeout is set to 500000 usec. We need to add an API to LLDB where we can specify the timeout for an expression.

llvm-svn: 165437

<rdar://problem/12200505> Fixing a logical error in SBProcess, where the get_process_thread_list function was creating invalid threads_access instances, and hence failing to correctly fill in the list

llvm-svn: 165421

Silly me! There was a closing ) missing from one of the lines - and Python complained about syntax errors on the next line. It being a Friday afternoon made the rest

llvm-svn: 165420

llvm-svn: 165410

llvm-svn: 165396

if we have a kernel binary, set the target's architecture to match.

Include the target's architecture in the ModuleSpec when we're searching for the 
kext binaries on the local system -- otherwise we won't get a specific slice of
a fat file picked out for us and we won't use the returned Module correctly.

Remove the redundant attempt to find a file on the local filesystem from this method.


In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark
the canJIT as false.  There is no jitting code in kernel debug sessions.

llvm-svn: 165357

starting lldb I get

% ./lldb -x
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/tmp/build/Debug/LLDB.framework/Versions/A/Resources/Python/lldb/__init__.py", line 9008
    raise TypeError("No array item of type %s" % str(type(key)))
        ^
SyntaxError: invalid syntax
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
(lldb)


I did a clean build and still got the problem so I'm backing this out until Enrico can
look at it.

llvm-svn: 165356

Make the error message from regex commands use the command's syntax string if it exists rather than a generic but
not at all helpful message about not matching some unknown regex...

llvm-svn: 165349

llvm-svn: 165348

llvm-svn: 165344

llvm-svn: 165341

it's too easy to type by mistake when typing "l" (read: I did this once).

llvm-svn: 165340

to watch var set/exp -- that's now the default in the
shipped lldb.

llvm-svn: 165333

Document "f <n>" selects frame n.  
"t <n>" selects thread n but this was just added to TOT
so most people won't have access to an lldb that accepts it.

llvm-svn: 165332

llvm-svn: 165330

llvm-svn: 165328

llvm-svn: 165327

llvm-svn: 165301

It is now a regex command alias that more faithfully emulates gdb's
behavior, most importantly, "bt 5" will backtrace 5 frames of the
currently selected thread.  "bt all" still backtraces all threads
(unlike gdb) and for users who have learned to use "bt -c 5", that
form is still accepted.

llvm-svn: 165300

expansion on the dSYM path we find if it starts with a tilde.

llvm-svn: 165299

llvm-svn: 165297

llvm-svn: 165296

reflect that the columns were just swapped.

llvm-svn: 165295

often hear feedback from people that having the lldb commands on
the left hand side is non-intuitive -- they say "I want a *gdb* to
*lldb* table, not a *lldb* to *gdb* table".  It doesn't seem odious
to go from the right-hand column to the left hand column but I've
heard this same feedback enough that it's also pointless to keep
the format lldb-first, gdb-second when it was an arbitrary choice
to begin with.

llvm-svn: 165294

<rdar://problem/12099999> renaming SBStream::Printf to Print in the scripting world in order to avoid supporting varargs through SWIG

llvm-svn: 165274

A tweak to the previous commit to ensure that we don't try to use -> on a NULL pointer (should not happen but better be safe than sorry)

llvm-svn: 165272

<rdar://problem/12413390> Fixing an issue where synthetic ValueObjects do not properly resolve their value

llvm-svn: 165271

enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing

        Mutex::Locker(m_map_mutex);

This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately.  Instead,

        Mutex::Locker locker(m_map_mutex);

does what is intended.  For some reason -Wshadow happened to
highlight these as shadowed variables.

I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>

llvm-svn: 165269

from LLVM and Clang.  This made "svn update" very
unpleasant if the original repository was fetched by
build-llvm.pl.

llvm-svn: 165268

because the unwinders typically can find its
value.

llvm-svn: 165266

ClangASTContext::GetIndexOfChildWithName - increment the child index we plan to return as we iterate through the ivars.

<rdar://problem/12433299>

llvm-svn: 165264

from a NULL ObjCInterfaceDecl.

llvm-svn: 165261

<rdar://problem/12424824> Making sure that we correctly update our synthetic children provider for NSDictionary - providing better support for dynamic types by letting the filter recalculate itself when the type of the object changes

llvm-svn: 165260

<rdar://problem/12424824> Making sure that we correctly update our synthetic children provider for NSArray - the same work will need to be done for NSDictionary

llvm-svn: 165252

ProcessGDBRemote and DynamicLoaderDarwinKernel and a patch was needed
to get this building on Linux.  Thanks!

llvm-svn: 165193

llvm-svn: 165192