maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Host/macosx/Symbols.cpp

560 lines
26 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- Symbols.cpp ---------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Host/Symbols.h"
// C Includes
#include <dirent.h>
Change the MacOSX Symbols::DownloadObjectAndSymbolFile to look up "~rc" via getpwnam() instead of doing tilde expansion and doing soft-link dereferencing via realpath() - if we're pointing to a softlink, leave it as-is. <rdar://problem/12597698> llvm-svn: 167052
2012-10-31 05:26:30 +08:00
#include <pwd.h>
Workaround for collision between enum members in LLVM's MachO.h and system headers on Mac OS X (in particular mach/machine.h). <rdar://problem/16494607> llvm-svn: 205480
2014-04-03 06:53:21 +08:00
#include "lldb/Utility/SafeMachO.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// C++ Includes
// Other libraries and framework includes
#include <CoreFoundation/CoreFoundation.h>
// Project includes
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataBuffer.h"
#include "lldb/Core/DataExtractor.h"
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
#include "lldb/Core/Log.h"
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
2012-02-26 13:51:37 +08:00
#include "lldb/Core/Module.h"
<rdar://problem/11757916> 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
2012-08-30 05:13:06 +08:00
#include "lldb/Core/ModuleSpec.h"
rdar://problem/11324515 '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
2012-08-22 08:18:43 +08:00
#include "lldb/Core/StreamString.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Timer.h"
#include "lldb/Core/UUID.h"
Endian patch from Kirk Beitz that allows better cross platform building. llvm-svn: 124643
2011-02-01 09:31:41 +08:00
#include "lldb/Host/Endian.h"
lldb should warn when dSYM does not match the binary. o Symbols.cpp: Emit a warning message when dSYM does not match the binary. o warnings/uuid: Added regression test case. o lldbtest.py: Modified to allow test case writer to demand that the build command does not begin with a clean first; required to make TestUUIDMismatchWanring.py work. rdar://problem/10515708 llvm-svn: 149465
2012-02-01 09:49:50 +08:00
#include "lldb/Host/Host.h"
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
#include "lldb/Symbol/ObjectFile.h"
Added a cleanup helper object to make sure the directory that was opened with "DIR *opendir(const char *)" is closed if it is valid with a call to "int closedir (DIR *)". llvm-svn: 124648
2011-02-01 13:15:02 +08:00
#include "lldb/Utility/CleanUp.h"
build: Fix an improperly formed include path (works under Xcode's promiscuous include additions, but not Makefiles). llvm-svn: 143382
2011-11-01 06:50:53 +08:00
#include "Host/macosx/cfcpp/CFCBundle.h"
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
#include "Host/macosx/cfcpp/CFCData.h"
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
#include "Host/macosx/cfcpp/CFCReleaser.h"
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#include "Host/macosx/cfcpp/CFCString.h"
eliminate some clang warnings. llvm-svn: 113438
2010-09-09 07:01:14 +08:00
#include "mach/machine.h"
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Change over to using the definitions for mach-o types and defines to the defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO and ObjectContainerUniversalMachO to be able to be cross compiled in Linux. Also did some cleanup on the ASTType by renaming it to ClangASTType and renaming the header file. Moved a lot of "AST * + opaque clang type *" functionality from lldb_private::Type over into ClangASTType. llvm-svn: 109046
2010-07-22 06:12:05 +08:00
using namespace llvm::MachO;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
__arm64__ and __aarch64__ #ifdef adjustments Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
2014-07-09 09:29:05 +08:00
#if !defined (__arm__) && !defined (__arm64__) && !defined (__aarch64__) // No DebugSymbols on the iOS devices
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
extern "C" {
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
CFURLRef DBGCopyFullDSYMURLForUUID (CFUUIDRef uuid, CFURLRef exec_url);
CFDictionaryRef DBGCopyDSYMPropertyLists (CFURLRef dsym_url);
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
int
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
LocateMacOSXFilesUsingDebugSymbols
(
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
2012-02-26 13:51:37 +08:00
const ModuleSpec &module_spec,
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
ModuleSpec &return_module_spec
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
)
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
return_module_spec = module_spec;
return_module_spec.GetFileSpec().Clear();
return_module_spec.GetSymbolFileSpec().Clear();
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
int items_found = 0;
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
__arm64__ and __aarch64__ #ifdef adjustments Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
2014-07-09 09:29:05 +08:00
#if !defined (__arm__) && !defined (__arm64__) && !defined (__aarch64__) // No DebugSymbols on the iOS devices
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
2012-02-26 13:51:37 +08:00
const UUID *uuid = module_spec.GetUUIDPtr();
const ArchSpec *arch = module_spec.GetArchitecturePtr();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (uuid && uuid->IsValid())
{
// Try and locate the dSYM file using DebugSymbols first
const UInt8 *module_uuid = (const UInt8 *)uuid->GetBytes();
if (module_uuid != NULL)
{
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
CFCReleaser<CFUUIDRef> module_uuid_ref(::CFUUIDCreateWithBytes (NULL,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
module_uuid[0],
module_uuid[1],
module_uuid[2],
module_uuid[3],
module_uuid[4],
module_uuid[5],
module_uuid[6],
module_uuid[7],
module_uuid[8],
module_uuid[9],
module_uuid[10],
module_uuid[11],
module_uuid[12],
module_uuid[13],
module_uuid[14],
module_uuid[15]));
if (module_uuid_ref.get())
{
CFCReleaser<CFURLRef> exec_url;
Made a ModuleSpec class in Module.h which can specify a module using one or more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
2012-02-26 13:51:37 +08:00
const FileSpec *exec_fspec = module_spec.GetFileSpecPtr();
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (exec_fspec)
{
char exec_cf_path[PATH_MAX];
if (exec_fspec->GetPath(exec_cf_path, sizeof(exec_cf_path)))
exec_url.reset(::CFURLCreateFromFileSystemRepresentation (NULL,
(const UInt8 *)exec_cf_path,
strlen(exec_cf_path),
FALSE));
}
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
CFCReleaser<CFURLRef> dsym_url (::DBGCopyFullDSYMURLForUUID(module_uuid_ref.get(), exec_url.get()));
char path[PATH_MAX];
if (dsym_url.get())
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
if (::CFURLGetFileSystemRepresentation (dsym_url.get(), true, (UInt8*)path, sizeof(path)-1))
{
if (log)
{
log->Printf ("DebugSymbols framework returned dSYM path of %s for UUID %s -- looking for the dSYM", path, uuid->GetAsString().c_str());
}
FileSpec dsym_filespec(path, path[0] == '~');
if (dsym_filespec.GetFileType () == FileSpec::eFileTypeDirectory)
{
dsym_filespec = Symbols::FindSymbolFileInBundle (dsym_filespec, uuid, arch);
++items_found;
}
else
{
++items_found;
}
return_module_spec.GetSymbolFileSpec() = dsym_filespec;
}
bool success = false;
if (log)
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 248985
2015-10-01 13:37:22 +08:00
{
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
if (::CFURLGetFileSystemRepresentation (dsym_url.get(), true, (UInt8*)path, sizeof(path)-1))
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 248985
2015-10-01 13:37:22 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
log->Printf ("DebugSymbols framework returned dSYM path of %s for UUID %s -- looking for an exec file", path, uuid->GetAsString().c_str());
}
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
}
CFCReleaser<CFDictionaryRef> dict(::DBGCopyDSYMPropertyLists (dsym_url.get()));
CFDictionaryRef uuid_dict = NULL;
if (dict.get())
{
CFCString uuid_cfstr (uuid->GetAsString().c_str());
uuid_dict = static_cast<CFDictionaryRef>(::CFDictionaryGetValue (dict.get(), uuid_cfstr.get()));
}
if (uuid_dict)
{
CFStringRef exec_cf_path = static_cast<CFStringRef>(::CFDictionaryGetValue (uuid_dict, CFSTR("DBGSymbolRichExecutable")));
if (exec_cf_path && ::CFStringGetFileSystemRepresentation (exec_cf_path, path, sizeof(path)))
{
if (log)
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
log->Printf ("plist bundle has exec path of %s for UUID %s", path, uuid->GetAsString().c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
++items_found;
FileSpec exec_filespec (path, path[0] == '~');
if (exec_filespec.Exists())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
success = true;
return_module_spec.GetFileSpec() = exec_filespec;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
if (!success)
<rdar://problem/8196933> Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available. llvm-svn: 152836
2012-03-16 05:01:31 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
// No dictionary, check near the dSYM bundle for an executable that matches...
if (::CFURLGetFileSystemRepresentation (dsym_url.get(), true, (UInt8*)path, sizeof(path)-1))
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
char *dsym_extension_pos = ::strstr (path, ".dSYM");
if (dsym_extension_pos)
<rdar://problem/8196933> Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available. llvm-svn: 152836
2012-03-16 05:01:31 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
*dsym_extension_pos = '\0';
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
if (log)
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
log->Printf ("Looking for executable binary next to dSYM bundle with name with name %s", path);
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
}
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
FileSpec file_spec (path, true);
ModuleSpecList module_specs;
ModuleSpec matched_module_spec;
switch (file_spec.GetFileType())
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
case FileSpec::eFileTypeDirectory: // Bundle directory?
{
CFCBundle bundle (path);
CFCReleaser<CFURLRef> bundle_exe_url (bundle.CopyExecutableURL ());
if (bundle_exe_url.get())
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
if (::CFURLGetFileSystemRepresentation (bundle_exe_url.get(), true, (UInt8*)path, sizeof(path)-1))
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
FileSpec bundle_exe_file_spec (path, true);
if (ObjectFile::GetModuleSpecifications(bundle_exe_file_spec, 0, 0, module_specs) &&
module_specs.FindMatchingModuleSpec(module_spec, matched_module_spec))
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..." This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
2015-10-01 17:03:33 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
{
++items_found;
return_module_spec.GetFileSpec() = bundle_exe_file_spec;
if (log)
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
log->Printf ("Executable binary %s next to dSYM is compatible; using", path);
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
}
}
}
}
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
}
break;
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
case FileSpec::eFileTypePipe: // Forget pipes
case FileSpec::eFileTypeSocket: // We can't process socket files
case FileSpec::eFileTypeInvalid: // File doesn't exist...
break;
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
case FileSpec::eFileTypeUnknown:
case FileSpec::eFileTypeRegular:
case FileSpec::eFileTypeSymbolicLink:
case FileSpec::eFileTypeOther:
if (ObjectFile::GetModuleSpecifications(file_spec, 0, 0, module_specs) &&
module_specs.FindMatchingModuleSpec(module_spec, matched_module_spec))
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
{
++items_found;
return_module_spec.GetFileSpec() = file_spec;
if (log)
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
{
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
log->Printf ("Executable binary %s next to dSYM is compatible; using", path);
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
}
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
}
break;
Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate an executable file if it is right next to a dSYM file that is found using DebugSymbols. The code also looks into a bundle if the dSYM file is right next to a bundle. Modified the MacOSX kernel dynamic loader plug-in to correctly set the load address for kext sections. This is a tad tricky because of how LLDB chooses to treat mach-o segments with no name. Also modified the loader to properly handle the older version 1 kext summary info. Fixed a crasher in the Mach-o object file parser when it is trying to set the section size correctly for dSYM sections. Added packet dumpers to the CommunicationKDP class. We now also properly detect address byte sizes based on the cpu type and subtype that is provided. Added a read memory and read register support to CommunicationKDP. Added a ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for arm, i386 and x86_64. Fixed some register numbering issues in the RegisterContextDarwin_arm class and added ARM GDB numbers to the ARM_GCC_Registers.h file. Change the RegisterContextMach_XXX classes over to subclassing their RegisterContextDarwin_XXX counterparts so we can share the mach register contexts between the user and kernel plug-ins. llvm-svn: 135466
2011-07-19 11:57:15 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
}
}
}
__arm64__ and __aarch64__ #ifdef adjustments Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
2014-07-09 09:29:05 +08:00
#endif // #if !defined (__arm__) && !defined (__arm64__) && !defined (__aarch64__)
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return items_found;
}
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
FileSpec
Symbols::FindSymbolFileInBundle (const FileSpec& dsym_bundle_fspec,
const lldb_private::UUID *uuid,
const ArchSpec *arch)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
char path[PATH_MAX];
FileSpec dsym_fspec;
if (dsym_bundle_fspec.GetPath(path, sizeof(path)))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
::strncat (path, "/Contents/Resources/DWARF", sizeof(path) - strlen(path) - 1);
lldb_utility::CleanUp <DIR *, int> dirp (opendir(path), NULL, closedir);
if (dirp.is_valid())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
dsym_fspec.GetDirectory().SetCString(path);
struct dirent* dp;
while ((dp = readdir(dirp.get())) != NULL)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
// Only search directories
if (dp->d_type == DT_DIR || dp->d_type == DT_UNKNOWN)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
if (dp->d_namlen == 1 && dp->d_name[0] == '.')
continue;
if (dp->d_namlen == 2 && dp->d_name[0] == '.' && dp->d_name[1] == '.')
continue;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
if (dp->d_type == DT_REG || dp->d_type == DT_UNKNOWN)
{
dsym_fspec.GetFilename().SetCString(dp->d_name);
ModuleSpecList module_specs;
if (ObjectFile::GetModuleSpecifications(dsym_fspec, 0, 0, module_specs))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
ModuleSpec spec;
for (size_t i = 0; i < module_specs.GetSize(); ++i)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
assert(module_specs.GetModuleSpecAtIndex(i, spec));
if ((uuid == NULL || (spec.GetUUIDPtr() && spec.GetUUID() == *uuid)) &&
(arch == NULL || (spec.GetArchitecturePtr() && spec.GetArchitecture().IsCompatibleMatch(*arch))))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
return dsym_fspec;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
}
}
}
dsym_fspec.Clear();
Look for both .debug and dsym debugging symbol information for stripped executable. Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external dsym debugging information, however if running on a stripped dwarf executable it should also check for a .debug file as well. Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py This test now passes when running a remote Mac -> Linux test, and still passes running locally on Mac or locally on Linux. Differential Revision: http://reviews.llvm.org/D9174 llvm-svn: 235737
2015-04-25 02:09:54 +08:00
return dsym_fspec;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
static bool
GetModuleSpecInfoFromUUIDDictionary (CFDictionaryRef uuid_dict, ModuleSpec &module_spec)
{
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
bool success = false;
if (uuid_dict != NULL && CFGetTypeID (uuid_dict) == CFDictionaryGetTypeID ())
{
std::string str;
CFStringRef cf_str;
cf_str = (CFStringRef)CFDictionaryGetValue ((CFDictionaryRef) uuid_dict, CFSTR("DBGSymbolRichExecutable"));
if (cf_str && CFGetTypeID (cf_str) == CFStringGetTypeID ())
{
if (CFCString::FileSystemRepresentation(cf_str, str))
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
{
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
module_spec.GetFileSpec().SetFile (str.c_str(), true);
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
if (log)
{
log->Printf ("From dsymForUUID plist: Symbol rich executable is at '%s'", str.c_str());
}
}
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
}
cf_str = (CFStringRef)CFDictionaryGetValue ((CFDictionaryRef) uuid_dict, CFSTR("DBGDSYMPath"));
if (cf_str && CFGetTypeID (cf_str) == CFStringGetTypeID ())
{
if (CFCString::FileSystemRepresentation(cf_str, str))
{
module_spec.GetSymbolFileSpec().SetFile (str.c_str(), true);
success = true;
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
if (log)
{
log->Printf ("From dsymForUUID plist: dSYM is at '%s'", str.c_str());
}
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
}
}
cf_str = (CFStringRef)CFDictionaryGetValue ((CFDictionaryRef) uuid_dict, CFSTR("DBGArchitecture"));
if (cf_str && CFGetTypeID (cf_str) == CFStringGetTypeID ())
{
if (CFCString::FileSystemRepresentation(cf_str, str))
module_spec.GetArchitecture().SetTriple(str.c_str());
}
std::string DBGBuildSourcePath;
std::string DBGSourcePath;
cf_str = (CFStringRef)CFDictionaryGetValue ((CFDictionaryRef) uuid_dict, CFSTR("DBGBuildSourcePath"));
if (cf_str && CFGetTypeID (cf_str) == CFStringGetTypeID ())
{
CFCString::FileSystemRepresentation(cf_str, DBGBuildSourcePath);
}
cf_str = (CFStringRef)CFDictionaryGetValue ((CFDictionaryRef) uuid_dict, CFSTR("DBGSourcePath"));
if (cf_str && CFGetTypeID (cf_str) == CFStringGetTypeID ())
{
CFCString::FileSystemRepresentation(cf_str, DBGSourcePath);
}
if (!DBGBuildSourcePath.empty() && !DBGSourcePath.empty())
{
module_spec.GetSourceMappingList().Append (ConstString(DBGBuildSourcePath.c_str()), ConstString(DBGSourcePath.c_str()), true);
}
}
return success;
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
bool
Add a parameter to Symbols::DownloadObjectAndSymbolFile() to control 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
2012-10-09 09:17:11 +08:00
Symbols::DownloadObjectAndSymbolFile (ModuleSpec &module_spec, bool force_lookup)
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
bool success = false;
const UUID *uuid_ptr = module_spec.GetUUIDPtr();
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
const FileSpec *file_spec_ptr = module_spec.GetFileSpecPtr();
Add a parameter to Symbols::DownloadObjectAndSymbolFile() to control 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
2012-10-09 09:17:11 +08:00
// It's expensive to check for the DBGShellCommands defaults setting, only do it once per
// lldb run and cache the result.
static bool g_have_checked_for_dbgshell_command = false;
static const char *g_dbgshell_command = NULL;
if (g_have_checked_for_dbgshell_command == false)
{
g_have_checked_for_dbgshell_command = true;
CFTypeRef defaults_setting = CFPreferencesCopyAppValue (CFSTR ("DBGShellCommands"), CFSTR ("com.apple.DebugSymbols"));
if (defaults_setting && CFGetTypeID (defaults_setting) == CFStringGetTypeID())
{
char cstr_buf[PATH_MAX];
if (CFStringGetCString ((CFStringRef) defaults_setting, cstr_buf, sizeof (cstr_buf), kCFStringEncodingUTF8))
{
g_dbgshell_command = strdup (cstr_buf); // this malloc'ed memory will never be freed
}
}
if (defaults_setting)
{
CFRelease (defaults_setting);
}
}
// When g_dbgshell_command is NULL, the user has not enabled the use of an external program
// to find the symbols, don't run it for them.
if (force_lookup == false && g_dbgshell_command == NULL)
{
return false;
}
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
if (uuid_ptr || (file_spec_ptr && file_spec_ptr->Exists()))
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
static bool g_located_dsym_for_uuid_exe = false;
static bool g_dsym_for_uuid_exe_exists = false;
static char g_dsym_for_uuid_exe_path[PATH_MAX];
if (!g_located_dsym_for_uuid_exe)
{
g_located_dsym_for_uuid_exe = true;
const char *dsym_for_uuid_exe_path_cstr = getenv("LLDB_APPLE_DSYMFORUUID_EXECUTABLE");
FileSpec dsym_for_uuid_exe_spec;
if (dsym_for_uuid_exe_path_cstr)
{
dsym_for_uuid_exe_spec.SetFile(dsym_for_uuid_exe_path_cstr, true);
g_dsym_for_uuid_exe_exists = dsym_for_uuid_exe_spec.Exists();
}
if (!g_dsym_for_uuid_exe_exists)
{
Change the MacOSX Symbols::DownloadObjectAndSymbolFile to look up "~rc" via getpwnam() instead of doing tilde expansion and doing soft-link dereferencing via realpath() - if we're pointing to a softlink, leave it as-is. <rdar://problem/12597698> llvm-svn: 167052
2012-10-31 05:26:30 +08:00
dsym_for_uuid_exe_spec.SetFile("/usr/local/bin/dsymForUUID", false);
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
g_dsym_for_uuid_exe_exists = dsym_for_uuid_exe_spec.Exists();
if (!g_dsym_for_uuid_exe_exists)
{
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
long bufsize;
Change the MacOSX Symbols::DownloadObjectAndSymbolFile to look up "~rc" via getpwnam() instead of doing tilde expansion and doing soft-link dereferencing via realpath() - if we're pointing to a softlink, leave it as-is. <rdar://problem/12597698> llvm-svn: 167052
2012-10-31 05:26:30 +08:00
if ((bufsize = sysconf(_SC_GETPW_R_SIZE_MAX)) != -1)
{
char buffer[bufsize];
struct passwd pwd;
struct passwd *tilde_rc = NULL;
// we are a library so we need to use the reentrant version of getpwnam()
if (getpwnam_r ("rc", &pwd, buffer, bufsize, &tilde_rc) == 0
&& tilde_rc
&& tilde_rc->pw_dir)
{
std::string dsymforuuid_path(tilde_rc->pw_dir);
dsymforuuid_path += "/bin/dsymForUUID";
dsym_for_uuid_exe_spec.SetFile(dsymforuuid_path.c_str(), false);
g_dsym_for_uuid_exe_exists = dsym_for_uuid_exe_spec.Exists();
}
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
}
}
Add a parameter to Symbols::DownloadObjectAndSymbolFile() to control 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
2012-10-09 09:17:11 +08:00
if (!g_dsym_for_uuid_exe_exists && g_dbgshell_command != NULL)
{
dsym_for_uuid_exe_spec.SetFile(g_dbgshell_command, true);
g_dsym_for_uuid_exe_exists = dsym_for_uuid_exe_spec.Exists();
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
if (g_dsym_for_uuid_exe_exists)
dsym_for_uuid_exe_spec.GetPath (g_dsym_for_uuid_exe_path, sizeof(g_dsym_for_uuid_exe_path));
}
if (g_dsym_for_uuid_exe_exists)
{
Remove the UUID::GetAsCString() method which required a buffer to save the UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
2013-05-04 07:56:12 +08:00
std::string uuid_str;
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
char file_path[PATH_MAX];
file_path[0] = '\0';
if (uuid_ptr)
Remove the UUID::GetAsCString() method which required a buffer to save the UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
2013-05-04 07:56:12 +08:00
uuid_str = uuid_ptr->GetAsString();
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
if (file_spec_ptr)
file_spec_ptr->GetPath(file_path, sizeof(file_path));
StreamString command;
Remove the UUID::GetAsCString() method which required a buffer to save the UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
2013-05-04 07:56:12 +08:00
if (!uuid_str.empty())
Jim thinks we shouldn't bother to pollute the svn repo with these internal details, so I'll pull it back to just our own branch of the sources. llvm-svn: 252254
2015-11-06 08:55:17 +08:00
command.Printf("%s --ignoreNegativeCache --copyExecutable %s", g_dsym_for_uuid_exe_path, uuid_str.c_str());
Remove always-true part of a conditional expression. clang warning. llvm-svn: 220018
2014-10-17 09:38:10 +08:00
else if (file_path[0] != '\0')
Jim thinks we shouldn't bother to pollute the svn repo with these internal details, so I'll pull it back to just our own branch of the sources. llvm-svn: 252254
2015-11-06 08:55:17 +08:00
command.Printf("%s --ignoreNegativeCache --copyExecutable %s", g_dsym_for_uuid_exe_path, file_path);
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
if (!command.GetString().empty())
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
int exit_status = -1;
int signo = -1;
std::string command_output;
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
if (log)
{
if (!uuid_str.empty())
log->Printf("Calling %s with UUID %s to find dSYM", g_dsym_for_uuid_exe_path, uuid_str.c_str());
else if (file_path[0] != '\0')
log->Printf("Calling %s with file %s to find dSYM", g_dsym_for_uuid_exe_path, file_path);
}
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
Error error = Host::RunShellCommand (command.GetData(),
NULL, // current working directory
&exit_status, // Exit status
&signo, // Signal int *
&command_output, // Command output
30, // Large timeout to allow for long dsym download times
Fix a -Wnull-conversion warning. llvm-svn: 226181
2015-01-16 01:55:24 +08:00
false); // Don't run in a shell (we don't need shell expansion)
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
if (error.Success() && exit_status == 0 && !command_output.empty())
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
CFCData data (CFDataCreateWithBytesNoCopy (NULL,
(const UInt8 *)command_output.data(),
command_output.size(),
kCFAllocatorNull));
CFCReleaser<CFDictionaryRef> plist((CFDictionaryRef)::CFPropertyListCreateFromXMLData (NULL, data.get(), kCFPropertyListImmutable, NULL));
Fixed a crash when we didn't get a plist but tried to pass it to CFGetTypeID() anyway. <rdar://problem/13181904> llvm-svn: 174772
2013-02-09 07:17:17 +08:00
if (plist.get() && CFGetTypeID (plist.get()) == CFDictionaryGetTypeID ())
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Remove the UUID::GetAsCString() method which required a buffer to save the UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
2013-05-04 07:56:12 +08:00
if (!uuid_str.empty())
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Remove the UUID::GetAsCString() method which required a buffer to save the UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
2013-05-04 07:56:12 +08:00
CFCString uuid_cfstr(uuid_str.c_str());
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
CFDictionaryRef uuid_dict = (CFDictionaryRef)CFDictionaryGetValue (plist.get(), uuid_cfstr.get());
success = GetModuleSpecInfoFromUUIDDictionary (uuid_dict, module_spec);
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
}
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
else
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
const CFIndex num_values = ::CFDictionaryGetCount(plist.get());
if (num_values > 0)
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
std::vector<CFStringRef> keys (num_values, NULL);
std::vector<CFDictionaryRef> values (num_values, NULL);
::CFDictionaryGetKeysAndValues(plist.get(), NULL, (const void **)&values[0]);
if (num_values == 1)
{
return GetModuleSpecInfoFromUUIDDictionary (values[0], module_spec);
}
else
{
for (CFIndex i=0; i<num_values; ++i)
{
ModuleSpec curr_module_spec;
if (GetModuleSpecInfoFromUUIDDictionary (values[i], curr_module_spec))
{
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
if (module_spec.GetArchitecture().IsCompatibleMatch(curr_module_spec.GetArchitecture()))
Wrapped up the work I am going to do for now for the "add-dsym" or "target 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
2012-09-28 06:26:11 +08:00
{
module_spec = curr_module_spec;
return true;
}
}
}
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
}
}
}
}
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
else
{
if (log)
{
if (!uuid_str.empty())
log->Printf("Called %s on %s, no matches", g_dsym_for_uuid_exe_path, uuid_str.c_str());
else if (file_path[0] != '\0')
log->Printf("Called %s on %s, no matches", g_dsym_for_uuid_exe_path, file_path);
}
}
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
}
}
}
return success;
}