I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
ConstString Host::GetVendorString();
ConstString Host::GetOSString();
comes from. It now all comes from the Host::GetArchitecture (eSystemDefaultArchitecture) like the Apple build was doing to minimize the number of places that need to be updated when Host::GetArchitecture () is called.
llvm-svn: 165805
Dynamic type code must be efficient and fast. Now it is.
Added ObjC v1 support for getting the complete list of ISA values.
The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.
Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.
llvm-svn: 165730
with ~, we need to realpath it. Fixes the case where
settings set target.expr-prefix ~/lldb.prefix.header
wouldn't read this prefix header file. <rdar://problem/12475676>
llvm-svn: 165704
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
over to simply update its cache and then look up
the descriptor in the cache. This is fine because
the cache now builds much faster (since descriptors
are minimal).
Metaclasses aren't in the cache, so I switched
the Describe method for class descriptors from using
GetClassDescriptor to manually creating an automatic
ClassDescriptorV2.
llvm-svn: 165579
The following are now derived lazily:
- The name of the class (cached);
- the instance size of the class (not cached);
The following have been removed entirely:
- Whether the class is realized. This is an
implementation detail.
- The contents of the objc_class object. That
object can be read as needed.
- Whether the class is valid. The fact that
we vended a class to begin with means it's
valid. We will only give up looking parts
of it up if they are not in the format we
expect.
llvm-svn: 165567
lighter-weight so that the cache can be populated
faster.
- I Added a ProcessWP to the runtime so I can
take it out of the individual descriptors, saving
space;
- I made the constructors for the descriptors
private so that only the runtime can invoke them;
and
- I removed the constructor that takes a ValueObject
since the logic for using a ValueObject is in the
runtime.
llvm-svn: 165549
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
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
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
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
top-of-tree. Removed all local patches and llvm.zip.
The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur. Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.
llvm-svn: 164563
where the descriptor took a pointer to an object and
expected the Initialize function to dereference that
pointer and extract the isa value. This caused one
of our tests to fail.
llvm-svn: 164353
KDP -- now with rudimentary process control (continue only) and read + write registers (which means we can see stack frames) for x86_64, i386 and ARM.
llvm-svn: 164352
not correctly store the contents of Objective-C
classes. This was due to a combination of
factors:
1) Types were only being completed if we were
looking inside them for specific ivars
(using FindExternalVisibleDeclsByName).
We now look the complete type up at every
FindExternalLexicalDecls.
2) Even if the types were completed properly,
ValueObjectConstResult overrode the type
of every ValueObject using the complete type
for its class from the debug information.
Superclasses of complete classes are not
guaranteed to be complete. Although "frame
variable" uses the debug information,
the expression parser does now piece together
complete types at every level (as described
in Bullet 1), so I provided a way for the
expression parser to prevent overriding.
3) Type sizes were being miscomputed by
ClangASTContext. It ignored the ISA pointer
and only counted fields. We now correctly
count the ISA in the size of an object.
<rdar://problem/12315386>
llvm-svn: 164333
We can now read the relevant data structures for
the method list, and use a callback mechanism to
report their details to the AppleObjCTypeVendor,
which constructs appropriate Clang types.
llvm-svn: 164310
data structures more rapidly. Also added fields
for the other data structures in a class.
I also fixed a problem where I accidentally used
hasExternalLexicalStorage() instead of
hasExternalVisibleStorage() to mark an
incomplete object.
llvm-svn: 164197
Greg Clayton