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

345 lines
9.3 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.
//
//===----------------------------------------------------------------------===//
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/Broadcaster.h"
#include "lldb/Core/Event.h"
#include "lldb/Core/State.h"
#include "lldb/Core/Timer.h"
#include "lldb/Host/Host.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"
using namespace lldb;
using namespace lldb_private;
//----------------------------------------------------------------------
// TargetList constructor
//----------------------------------------------------------------------
TargetList::TargetList() :
Broadcaster("TargetList"),
m_target_list(),
m_target_list_mutex (Mutex::eMutexTypeRecursive),
m_selected_target_idx (0)
{
}
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
TargetList::~TargetList()
{
Mutex::Locker locker(m_target_list_mutex);
m_target_list.clear();
}
Error
TargetList::CreateTarget
(
Debugger &debugger,
const FileSpec& file,
const ArchSpec& arch,
bool get_dependent_files,
TargetSP &target_sp
)
{
Timer scoped_timer (__PRETTY_FUNCTION__,
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
"TargetList::CreateTarget (file = '%s/%s', arch = '%s')",
file.GetDirectory().AsCString(),
file.GetFilename().AsCString(),
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
arch.GetArchitectureName());
Error error;
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)
{
ModuleSP exe_module_sp;
FileSpec resolved_file(file);
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
ArchSpec platform_arch;
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
PlatformSP platform_sp (Platform::GetSelectedPlatform ());
if (platform_sp)
error = platform_sp->ResolveExecutable (file, arch, 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 (error.Success() && exe_module_sp)
{
if (exe_module_sp->GetObjectFile() == NULL)
{
if (arch.IsValid())
{
error.SetErrorStringWithFormat("\"%s%s%s\" doesn't contain architecture %s",
file.GetDirectory().AsCString(),
file.GetDirectory() ? "/" : "",
file.GetFilename().AsCString(),
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%s%s\"",
file.GetDirectory().AsCString(),
file.GetDirectory() ? "/" : "",
file.GetFilename().AsCString());
}
return error;
}
target_sp.reset(new Target(debugger));
target_sp->SetExecutableModule (exe_module_sp, get_dependent_files);
}
}
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
target_sp.reset(new Target(debugger));
if (arch.IsValid())
target_sp->SetArchitecture(arch);
}
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)
{
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
target_sp->UpdateInstanceName();
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 = exe_file_spec.GetDirectory();
collection::const_iterator pos, end = m_target_list.end();
for (pos = m_target_list.begin(); pos != end; ++pos)
{
ModuleSP module_sp ((*pos)->GetExecutableModule());
if (module_sp)
{
if (FileSpec::Equal (exe_file_spec, module_sp->GetFileSpec(), full_match))
{
if (exe_arch_ptr)
{
if (*exe_arch_ptr != module_sp->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->BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
++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::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);
}