llvm-project/lldb/source/Target/TargetList.cpp

666 lines
23 KiB
C++
Raw Normal View History

//===-- TargetList.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/lldb-python.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/Broadcaster.h"
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Event.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/Module.h"
#include "lldb/Core/ModuleSpec.h"
#include "lldb/Core/State.h"
#include "lldb/Core/Timer.h"
#include "lldb/Host/Host.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/OptionGroupPlatform.h"
#include "lldb/Symbol/ObjectFile.h"
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
#include "lldb/Target/Platform.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/TargetList.h"
#include "llvm/ADT/SmallString.h"
using namespace lldb;
using namespace lldb_private;
ConstString &
TargetList::GetStaticBroadcasterClass ()
{
static ConstString class_name ("lldb.targetList");
return class_name;
}
//----------------------------------------------------------------------
// TargetList constructor
//----------------------------------------------------------------------
TargetList::TargetList(Debugger &debugger) :
Broadcaster(&debugger, TargetList::GetStaticBroadcasterClass().AsCString()),
m_target_list(),
m_target_list_mutex (Mutex::eMutexTypeRecursive),
m_selected_target_idx (0)
{
CheckInWithManager();
}
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
TargetList::~TargetList()
{
Mutex::Locker locker(m_target_list_mutex);
m_target_list.clear();
}
Error
TargetList::CreateTarget (Debugger &debugger,
const char *user_exe_path,
const char *triple_cstr,
bool get_dependent_files,
const OptionGroupPlatform *platform_options,
TargetSP &target_sp)
{
Error error;
PlatformSP platform_sp;
// This is purposely left empty unless it is specified by triple_cstr.
// If not initialized via triple_cstr, then the currently selected platform
// will set the architecture correctly.
const ArchSpec arch(triple_cstr);
if (triple_cstr && triple_cstr[0])
{
if (!arch.IsValid())
{
error.SetErrorStringWithFormat("invalid triple '%s'", triple_cstr);
return error;
}
}
ArchSpec platform_arch(arch);
bool prefer_platform_arch = false;
CommandInterpreter &interpreter = debugger.GetCommandInterpreter();
if (platform_options && platform_options->PlatformWasSpecified ())
{
const bool select_platform = true;
platform_sp = platform_options->CreatePlatformWithOptions (interpreter,
arch,
select_platform,
error,
platform_arch);
if (!platform_sp)
return error;
}
if (user_exe_path && user_exe_path[0])
{
ModuleSpecList module_specs;
ModuleSpec module_spec;
module_spec.GetFileSpec().SetFile(user_exe_path, true);
// Resolve the executable in case we are given a path to a application bundle
// like a .app bundle on MacOSX
Host::ResolveExecutableInBundle (module_spec.GetFileSpec());
lldb::offset_t file_offset = 0;
lldb::offset_t file_size = 0;
const size_t num_specs = ObjectFile::GetModuleSpecifications (module_spec.GetFileSpec(), file_offset, file_size, module_specs);
if (num_specs > 0)
{
ModuleSpec matching_module_spec;
if (num_specs == 1)
{
if (module_specs.GetModuleSpecAtIndex(0, matching_module_spec))
{
if (platform_arch.IsValid())
{
if (platform_arch.IsCompatibleMatch(matching_module_spec.GetArchitecture()))
{
// If the OS or vendor weren't specified, then adopt the module's
// architecture so that the platform matching can be more accurate
if (!platform_arch.TripleOSWasSpecified() || !platform_arch.TripleVendorWasSpecified())
{
prefer_platform_arch = true;
platform_arch = matching_module_spec.GetArchitecture();
}
}
else
{
error.SetErrorStringWithFormat("the specified architecture '%s' is not compatible with '%s' in '%s'",
platform_arch.GetTriple().str().c_str(),
matching_module_spec.GetArchitecture().GetTriple().str().c_str(),
module_spec.GetFileSpec().GetPath().c_str());
return error;
}
}
else
{
// Only one arch and none was specified
prefer_platform_arch = true;
platform_arch = matching_module_spec.GetArchitecture();
}
}
}
else
{
if (arch.IsValid())
{
module_spec.GetArchitecture() = arch;
if (module_specs.FindMatchingModuleSpec(module_spec, matching_module_spec))
{
prefer_platform_arch = true;
platform_arch = matching_module_spec.GetArchitecture();
}
}
else
{
// No architecture specified, check if there is only one platform for
// all of the architectures.
typedef std::vector<PlatformSP> PlatformList;
PlatformList platforms;
PlatformSP host_platform_sp = Platform::GetDefaultPlatform();
for (size_t i=0; i<num_specs; ++i)
{
ModuleSpec module_spec;
if (module_specs.GetModuleSpecAtIndex(i, module_spec))
{
// See if there was a selected platform and check that first
// since the user may have specified it.
if (platform_sp)
{
if (platform_sp->IsCompatibleArchitecture(module_spec.GetArchitecture(), false, NULL))
{
platforms.push_back(platform_sp);
continue;
}
}
// Next check the host platform it if wasn't already checked above
if (host_platform_sp && (!platform_sp || host_platform_sp->GetName() != platform_sp->GetName()))
{
if (host_platform_sp->IsCompatibleArchitecture(module_spec.GetArchitecture(), false, NULL))
{
platforms.push_back(host_platform_sp);
continue;
}
}
// Just find a platform that matches the architecture in the executable file
platforms.push_back(Platform::GetPlatformForArchitecture(module_spec.GetArchitecture(), nullptr));
}
}
Platform *platform_ptr = NULL;
for (const auto &the_platform_sp : platforms)
{
if (platform_ptr)
{
if (platform_ptr->GetName() != the_platform_sp->GetName())
{
platform_ptr = NULL;
break;
}
}
else
{
platform_ptr = the_platform_sp.get();
}
}
if (platform_ptr)
{
// All platforms for all modules in the exectuable match, so we can select this platform
platform_sp = platforms.front();
}
else
{
// More than one platform claims to support this file, so the --platform option must be specified
StreamString error_strm;
std::set<Platform *> platform_set;
error_strm.Printf ("more than one platform supports this executable (");
for (const auto &the_platform_sp : platforms)
{
if (platform_set.find(the_platform_sp.get()) == platform_set.end())
{
if (!platform_set.empty())
error_strm.PutCString(", ");
error_strm.PutCString(the_platform_sp->GetName().GetCString());
platform_set.insert(the_platform_sp.get());
}
}
error_strm.Printf("), use the --platform option to specify a platform");
error.SetErrorString(error_strm.GetString().c_str());
return error;
}
}
}
}
}
if (!platform_sp)
{
// Get the current platform and make sure it is compatible with the
// current architecture if we have a valid architecture.
platform_sp = debugger.GetPlatformList().GetSelectedPlatform ();
if (!prefer_platform_arch && arch.IsValid())
{
if (!platform_sp->IsCompatibleArchitecture(arch, false, &platform_arch))
platform_sp = Platform::GetPlatformForArchitecture(arch, &platform_arch);
}
else if (platform_arch.IsValid())
{
// if "arch" isn't valid, yet "platform_arch" is, it means we have an executable file with
// a single architecture which should be used
ArchSpec fixed_platform_arch;
if (!platform_sp->IsCompatibleArchitecture(platform_arch, false, &fixed_platform_arch))
platform_sp = Platform::GetPlatformForArchitecture(platform_arch, &fixed_platform_arch);
}
}
if (!platform_arch.IsValid())
platform_arch = arch;
error = TargetList::CreateTarget (debugger,
user_exe_path,
platform_arch,
get_dependent_files,
platform_sp,
target_sp);
return error;
}
Error
TargetList::CreateTarget (Debugger &debugger,
const char *user_exe_path,
const ArchSpec& specified_arch,
bool get_dependent_files,
PlatformSP &platform_sp,
TargetSP &target_sp)
{
Timer scoped_timer (__PRETTY_FUNCTION__,
"TargetList::CreateTarget (file = '%s', arch = '%s')",
user_exe_path,
specified_arch.GetArchitectureName());
Error error;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
ArchSpec arch(specified_arch);
if (arch.IsValid())
{
if (!platform_sp || !platform_sp->IsCompatibleArchitecture(arch, false, NULL))
platform_sp = Platform::GetPlatformForArchitecture(specified_arch, &arch);
}
if (!platform_sp)
platform_sp = debugger.GetPlatformList().GetSelectedPlatform();
if (!arch.IsValid())
arch = specified_arch;
FileSpec file (user_exe_path, false);
if (!file.Exists() && user_exe_path && user_exe_path[0] == '~')
{
// we want to expand the tilde but we don't want to resolve any symbolic links
// so we can't use the FileSpec constructor's resolve flag
llvm::SmallString<64> unglobbed_path(user_exe_path);
FileSpec::ResolveUsername(unglobbed_path);
if (unglobbed_path.empty())
file = FileSpec(user_exe_path, false);
else
file = FileSpec(unglobbed_path.c_str(), false);
}
bool user_exe_path_is_bundle = false;
char resolved_bundle_exe_path[PATH_MAX];
resolved_bundle_exe_path[0] = '\0';
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (file)
{
if (file.GetFileType() == FileSpec::eFileTypeDirectory)
user_exe_path_is_bundle = true;
if (file.IsRelativeToCurrentWorkingDirectory())
{
// Ignore paths that start with "./" and "../"
if (!((user_exe_path[0] == '.' && user_exe_path[1] == '/') ||
(user_exe_path[0] == '.' && user_exe_path[1] == '.' && user_exe_path[2] == '/')))
{
char cwd[PATH_MAX];
if (getcwd (cwd, sizeof(cwd)))
{
std::string cwd_user_exe_path (cwd);
cwd_user_exe_path += '/';
cwd_user_exe_path += user_exe_path;
FileSpec cwd_file (cwd_user_exe_path.c_str(), false);
if (cwd_file.Exists())
file = cwd_file;
}
}
}
ModuleSP exe_module_sp;
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (platform_sp)
{
FileSpecList executable_search_paths (Target::GetDefaultExecutableSearchPaths());
error = platform_sp->ResolveExecutable (file,
arch,
exe_module_sp,
executable_search_paths.GetSize() ? &executable_search_paths : NULL);
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (error.Success() && exe_module_sp)
{
if (exe_module_sp->GetObjectFile() == NULL)
{
if (arch.IsValid())
{
error.SetErrorStringWithFormat("\"%s\" doesn't contain architecture %s",
file.GetPath().c_str(),
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
arch.GetArchitectureName());
}
else
{
error.SetErrorStringWithFormat("unsupported file type \"%s\"",
file.GetPath().c_str());
}
return error;
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
target_sp.reset(new Target(debugger, arch, platform_sp));
target_sp->SetExecutableModule (exe_module_sp, get_dependent_files);
if (user_exe_path_is_bundle)
exe_module_sp->GetFileSpec().GetPath(resolved_bundle_exe_path, sizeof(resolved_bundle_exe_path));
}
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
else
{
// No file was specified, just create an empty target with any arch
// if a valid arch was specified
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
target_sp.reset(new Target(debugger, arch, platform_sp));
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (target_sp)
{
// Set argv0 with what the user typed, unless the user specified a
// directory. If the user specified a directory, then it is probably a
// bundle that was resolved and we need to use the resolved bundle path
if (user_exe_path)
{
// Use exactly what the user typed as the first argument when we exec or posix_spawn
if (user_exe_path_is_bundle && resolved_bundle_exe_path[0])
{
target_sp->SetArg0 (resolved_bundle_exe_path);
}
else
{
// Use resolved path
target_sp->SetArg0 (file.GetPath().c_str());
}
}
if (file.GetDirectory())
{
FileSpec file_dir;
file_dir.GetDirectory() = file.GetDirectory();
target_sp->GetExecutableSearchPaths ().Append (file_dir);
}
Mutex::Locker locker(m_target_list_mutex);
m_selected_target_idx = m_target_list.size();
m_target_list.push_back(target_sp);
}
return error;
}
bool
TargetList::DeleteTarget (TargetSP &target_sp)
{
Mutex::Locker locker(m_target_list_mutex);
collection::iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
if (pos->get() == target_sp.get())
{
m_target_list.erase(pos);
return true;
}
}
return false;
}
TargetSP
TargetList::FindTargetWithExecutableAndArchitecture
(
const FileSpec &exe_file_spec,
const ArchSpec *exe_arch_ptr
) const
{
Mutex::Locker locker (m_target_list_mutex);
TargetSP target_sp;
bool full_match = (bool)exe_file_spec.GetDirectory();
collection::const_iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
Module *exe_module = (*pos)->GetExecutableModulePointer();
if (exe_module)
{
if (FileSpec::Equal (exe_file_spec, exe_module->GetFileSpec(), full_match))
{
if (exe_arch_ptr)
{
if (!exe_arch_ptr->IsCompatibleMatch(exe_module->GetArchitecture()))
continue;
}
target_sp = *pos;
break;
}
}
}
return target_sp;
}
TargetSP
TargetList::FindTargetWithProcessID (lldb::pid_t pid) const
{
Mutex::Locker locker(m_target_list_mutex);
TargetSP target_sp;
collection::const_iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
Process* process = (*pos)->GetProcessSP().get();
if (process && process->GetID() == pid)
{
target_sp = *pos;
break;
}
}
return target_sp;
}
TargetSP
TargetList::FindTargetWithProcess (Process *process) const
{
TargetSP target_sp;
if (process)
{
Mutex::Locker locker(m_target_list_mutex);
collection::const_iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
if (process == (*pos)->GetProcessSP().get())
{
target_sp = *pos;
break;
}
}
}
return target_sp;
}
TargetSP
TargetList::GetTargetSP (Target *target) const
{
TargetSP target_sp;
if (target)
{
Mutex::Locker locker(m_target_list_mutex);
collection::const_iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
if (target == (*pos).get())
{
target_sp = *pos;
break;
}
}
}
return target_sp;
}
uint32_t
TargetList::SendAsyncInterrupt (lldb::pid_t pid)
{
uint32_t num_async_interrupts_sent = 0;
if (pid != LLDB_INVALID_PROCESS_ID)
{
TargetSP target_sp(FindTargetWithProcessID (pid));
if (target_sp.get())
{
Process* process = target_sp->GetProcessSP().get();
if (process)
{
process->SendAsyncInterrupt();
++num_async_interrupts_sent;
}
}
}
else
{
// We don't have a valid pid to broadcast to, so broadcast to the target
// list's async broadcaster...
BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
}
return num_async_interrupts_sent;
}
uint32_t
TargetList::SignalIfRunning (lldb::pid_t pid, int signo)
{
uint32_t num_signals_sent = 0;
Process *process = NULL;
if (pid == LLDB_INVALID_PROCESS_ID)
{
// Signal all processes with signal
Mutex::Locker locker(m_target_list_mutex);
collection::iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
process = (*pos)->GetProcessSP().get();
if (process)
{
if (process->IsAlive())
{
++num_signals_sent;
process->Signal (signo);
}
}
}
}
else
{
// Signal a specific process with signal
TargetSP target_sp(FindTargetWithProcessID (pid));
if (target_sp.get())
{
process = target_sp->GetProcessSP().get();
if (process)
{
if (process->IsAlive())
{
++num_signals_sent;
process->Signal (signo);
}
}
}
}
return num_signals_sent;
}
int
TargetList::GetNumTargets () const
{
Mutex::Locker locker (m_target_list_mutex);
return m_target_list.size();
}
lldb::TargetSP
TargetList::GetTargetAtIndex (uint32_t idx) const
{
TargetSP target_sp;
Mutex::Locker locker (m_target_list_mutex);
if (idx < m_target_list.size())
target_sp = m_target_list[idx];
return target_sp;
}
uint32_t
TargetList::GetIndexOfTarget (lldb::TargetSP target_sp) const
{
Mutex::Locker locker (m_target_list_mutex);
size_t num_targets = m_target_list.size();
for (size_t idx = 0; idx < num_targets; idx++)
{
if (target_sp == m_target_list[idx])
return idx;
}
return UINT32_MAX;
}
uint32_t
TargetList::SetSelectedTarget (Target* target)
{
Mutex::Locker locker (m_target_list_mutex);
collection::const_iterator pos,
begin = m_target_list.begin(),
end = m_target_list.end();
for (pos = begin; pos != end; ++pos)
{
if (pos->get() == target)
{
m_selected_target_idx = std::distance (begin, pos);
return m_selected_target_idx;
}
}
m_selected_target_idx = 0;
return m_selected_target_idx;
}
lldb::TargetSP
TargetList::GetSelectedTarget ()
{
Mutex::Locker locker (m_target_list_mutex);
if (m_selected_target_idx >= m_target_list.size())
m_selected_target_idx = 0;
return GetTargetAtIndex (m_selected_target_idx);
}