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

llvm-svn: 165186

llvm-svn: 165176

<rdar://problem/12408181> Fixing a bug where we would try to look for types in a module, and then fail to look for them anywhere else because the same SymbolContext was being passed everywhere

llvm-svn: 165169

llvm-svn: 165144

remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038> 

llvm-svn: 165080

the Symbols::LocateExecutableObjectFile method to locate kexts and
kernels instead of copying them out of the memory of the remote
system.  This is the fix for <rdar://problem/12416384>.

Fix a variable shadowing problem in
Symbols::LocateMacOSXFilesUsingDebugSymbols which caused the symbol
rich executable binaries to not be found even if they were listed
in the dSYM Info.plist.

Change Symbols::DownloadObjectAndSymbolFile to ignore dsymForUUID's
negative cache - this is typically being called by the user and we
should try even if there's a incorrect entry in the negative cache.

llvm-svn: 165061

Shared libraries on MacOSX were not properly being removed from the shared
module list when re-running a debug session due to an error in:

Module::MatchesModuleSpec()

llvm-svn: 164991

Reduce the amount of output that DynamicLoaderDarwinKernel
prints for each kext it loads.
<rdar://problem/7714201> 

llvm-svn: 164985

llvm-svn: 164973