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
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
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
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
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
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
which builds a Debug+Asserts build of Clang and
links LLDB against it. The Debug configuration
builds Clang with Release+Asserts, for faster
linking and smaller memory footprint when debugging
the build LLDB.
llvm-svn: 164573
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
This feature allows us to group test cases into logical groups (categories), and to only run a subset of test cases based on these categories.
Each test-case can have a new method getCategories(self): which returns a list of strings that are the categories to which the test case belongs.
If a test-case does not provide its own categories, we will look for categories in the class that contains the test case.
If that fails too, the default implementation looks for a .category file, which contains a comma separated list of strings.
The test suite will recurse look for .categories up until the top level directory (which we guarantee will have an empty .category file).
The driver dotest.py has a new --category <foo> option, which can be repeated, and specifies which categories of tests you want to run.
(example: ./dotest.py --category objc --category expression)
All tests that do not belong to any specified category will be skipped. Other filtering options still exist and should not interfere with category filtering.
A few tests have been categorized. Feel free to categorize others, and to suggest new categories that we could want to use.
All categories need to be validly defined in dotest.py, or the test suite will refuse to run when you use them as arguments to --category.
In the end, failures will be reported on a per-category basis, as well as in the usual format.
This is the very first stage of this feature. Feel free to chime in with ideas for improvements!
llvm-svn: 164403
Sean Callanan