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
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
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
When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name.
llvm-svn: 163868
Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.
llvm-svn: 163676
The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system.
Making this work required two basic changes:
1) Getting lldb to report that it could debug 32-bit processes
2) Changing an assumption about how ptrace works when debugging cross-platform
For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms. It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure.
For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size. However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant." I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written.
llvm-svn: 163398
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads
Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".
llvm-svn: 162366
'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.
llvm-svn: 162332
than being given the pthread_mutex_t from the Mutex and locks that. That allows us to
track ownership of the Mutex better.
Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)
llvm-svn: 158240
TestBackticksWithoutATarget.BackticksWithNoTargetTestCase was calling
GetDummyTarget() when executing for x86_64. When performing session
tearDown, it would get destroyed (and everything would be invalid (arch,
etc).
Then the test would run for i386. The dummy target wasn't being
reinitialized and was invalid. lldb complained that 'current process state
is unsuitable for expression parsing'.
llvm-svn: 156994
"lldb -a i386" doesn't set the calculator mode correctly if run on a 64 bit system.
The previous logic always used the current host architecture, not the default architecture. The default arch gets set into a static varaible in lldb_private::Target when an arch is set from the command line:
lldb -a i386
We now use the default arch correctly.
llvm-svn: 156680
On Lion, because the rights initially doesn't exist in /etc/authorization, if an admin user logs in and uses lldb within the first 5 minutes, it is possible to do AuthorizationCopyRights on LaunchUsingXPCRightName and get the rights back. As another security measure, we make sure that the LaunchUsingXPCRightName rights actually exists.
Removed Xcode as the user of the XPC service to shrink the security surface area.
llvm-svn: 156424
We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights.
As well, refactored a bit so that control flow is easier to read for other folks. Added more comments.
llvm-svn: 156423
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
Jason Molenda