| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
expansion on the dSYM path we find if it starts with a tilde.
llvm-svn: 165299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symfile add" command.
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
|
|
|
|
|
|
| |
UUID.
llvm-svn: 164753
|
|
|
|
| |
llvm-svn: 164291
|
|
|
|
|
|
| |
Some platforms don't support this modification.
llvm-svn: 164148
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
'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
|
|
|
|
| |
llvm-svn: 161374
|
|
|
|
| |
llvm-svn: 161209
|
|
|
|
| |
llvm-svn: 160770
|
|
|
|
|
|
| |
GC and non-GC apps. It will also quiet the static analyzer.
llvm-svn: 160390
|
|
|
|
| |
llvm-svn: 160338
|
|
|
|
| |
llvm-svn: 160212
|
|
|
|
| |
llvm-svn: 160158
|
|
|
|
|
|
|
|
|
| |
Also remove our dependency on UIKit & AppKit.
Cleaned up the project files a bit.
<rdar://problem/11814498>
llvm-svn: 160147
|
|
|
|
|
|
|
|
| |
path passed with -w
Test this functionality.
llvm-svn: 160130
|
|
|
|
| |
llvm-svn: 159798
|
|
|
|
| |
llvm-svn: 158890
|
|
|
|
|
|
|
|
| |
separate process group, otherwise ^C will both cause us to try to Stop it manually, AND send it a SIGINT, which can confuse us.
rdar://problem/11369230
llvm-svn: 157791
|
|
|
|
| |
llvm-svn: 157456
|
|
|
|
| |
llvm-svn: 157090
|
|
|
|
| |
llvm-svn: 157040
|
|
|
|
|
|
| |
Restore Xcode as a valid white list client using the XPC root launcher
llvm-svn: 157012
|
|
|
|
| |
llvm-svn: 156971
|
|
|
|
| |
llvm-svn: 156887
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 156359
|
|
|
|
| |
llvm-svn: 156264
|
|
|
|
| |
llvm-svn: 155687
|
|
|
|
| |
llvm-svn: 155527
|
|
|
|
| |
llvm-svn: 155272
|
|
|
|
| |
llvm-svn: 155093
|
|
|
|
| |
llvm-svn: 154975
|
|
|
|
| |
llvm-svn: 154887
|
|
|
|
| |
llvm-svn: 154650
|
|
|
|
| |
llvm-svn: 154252
|
|
|
|
| |
llvm-svn: 154148
|
|
|
|
|
|
| |
of a superfluous 'default' label.
llvm-svn: 153943
|
|
|
|
| |
llvm-svn: 153823
|
|
|
|
|
|
| |
malloc'ed string array.
llvm-svn: 153785
|
|
|
|
| |
llvm-svn: 153630
|
|
|
|
| |
llvm-svn: 153374
|
|
|
|
| |
llvm-svn: 153365
|
|
|
|
| |
llvm-svn: 153298
|
|
|
|
|
|
| |
Remove unused entitlements plist from debugserver.
llvm-svn: 152973
|
|
|
|
| |
llvm-svn: 152901
|