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
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
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
When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.
<rdar://problem/7714201>
llvm-svn: 164888
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
runtime, we read method signatures for both class
and instance methods out of the runtime data.
(lldb) fr var str
(NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'"
(lldb) expr str.length
(unsigned long long) $0 = 72
(lldb) expr [NSString stringWithCString:"Hello world!" encoding:1]
(id) $1 = 0x0000000105100050
(lldb) po $1
$1 = 0x0000000105100050 Hello world!
(lldb) fr var array1
(NSArray *) array1 = 0x000000010010a6e0 @"3 objects"
(lldb) expr array1.count
(unsigned long long) $0 = 3
(lldb) expr [array1 objectAtIndex:2]
(id) $1 = 0x00000001000025d0
(lldb) po $1
$1 = 0x00000001000025d0 array1 object3
Notice that both regular and property-style notation
work. I still need to add explicit support for
properties with non-default setters/getters.
This information is only queried if an Objective-C
object does not have debug information for a complete
type available. Otherwise we query debug information
as usual.
llvm-svn: 164878
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.
Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
Currently, the new API objects and features are not exposed via Python.
The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own
llvm-svn: 164865
We can now do:
Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>
Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib
Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>
Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame
llvm-svn: 164806
