Files
llvm/lldb/source/Target/Platform.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2252 lines
78 KiB
C++
Raw Normal View History

//===-- Platform.cpp ------------------------------------------------------===//
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-08 22:40:15 +00:00
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
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-08 22:40:15 +00:00
//
//===----------------------------------------------------------------------===//
#include <algorithm>
#include <csignal>
#include <fstream>
#include <memory>
#include <optional>
#include <vector>
#include "lldb/Breakpoint/BreakpointIDList.h"
#include "lldb/Breakpoint/BreakpointLocation.h"
#include "lldb/Core/Debugger.h"
#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-29 21:13:06 +00:00
#include "lldb/Core/ModuleSpec.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-08 22:40:15 +00:00
#include "lldb/Core/PluginManager.h"
#include "lldb/Host/FileCache.h"
#include "lldb/Host/FileSystem.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 01:12:21 +00:00
#include "lldb/Host/Host.h"
#include "lldb/Host/HostInfo.h"
#include "lldb/Host/OptionParser.h"
#include "lldb/Interpreter/OptionValueFileSpec.h"
#include "lldb/Interpreter/OptionValueProperties.h"
#include "lldb/Interpreter/Property.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/ModuleCache.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 05:54:46 +00:00
#include "lldb/Target/Platform.h"
#include "lldb/Target/Process.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-08 22:40:15 +00:00
#include "lldb/Target/Target.h"
#include "lldb/Target/UnixSignals.h"
#include "lldb/Utility/DataBufferHeap.h"
#include "lldb/Utility/FileSpec.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Status.h"
#include "lldb/Utility/StructuredData.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
// Define these constants from POSIX mman.h rather than include the file so
// that they will be correct even when compiled on Linux.
#define MAP_PRIVATE 2
#define MAP_ANON 0x1000
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-08 22:40:15 +00:00
using namespace lldb;
using namespace lldb_private;
// Use a singleton function for g_local_platform_sp to avoid init constructors
// since LLDB is often part of a shared library
static PlatformSP &GetHostPlatformSP() {
static PlatformSP g_platform_sp;
return g_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-08 22:40:15 +00:00
}
const char *Platform::GetHostPlatformName() { return "host"; }
namespace {
#define LLDB_PROPERTIES_platform
#include "TargetProperties.inc"
enum {
#define LLDB_PROPERTIES_platform
#include "TargetPropertiesEnum.inc"
};
} // namespace
llvm::StringRef PlatformProperties::GetSettingName() {
static constexpr llvm::StringLiteral g_setting_name("platform");
return g_setting_name;
}
PlatformProperties::PlatformProperties() {
m_collection_sp = std::make_shared<OptionValueProperties>(GetSettingName());
m_collection_sp->Initialize(g_platform_properties);
auto module_cache_dir = GetModuleCacheDirectory();
if (module_cache_dir)
return;
llvm::SmallString<64> user_home_dir;
if (!FileSystem::Instance().GetHomeDirectory(user_home_dir))
return;
module_cache_dir = FileSpec(user_home_dir.c_str());
module_cache_dir.AppendPathComponent(".lldb");
module_cache_dir.AppendPathComponent("module_cache");
SetDefaultModuleCacheDirectory(module_cache_dir);
SetModuleCacheDirectory(module_cache_dir);
}
bool PlatformProperties::GetUseModuleCache() const {
const auto idx = ePropertyUseModuleCache;
return GetPropertyAtIndexAs<bool>(
idx, g_platform_properties[idx].default_uint_value != 0);
}
bool PlatformProperties::SetUseModuleCache(bool use_module_cache) {
return SetPropertyAtIndex(ePropertyUseModuleCache, use_module_cache);
}
FileSpec PlatformProperties::GetModuleCacheDirectory() const {
return GetPropertyAtIndexAs<FileSpec>(ePropertyModuleCacheDirectory, {});
}
bool PlatformProperties::SetModuleCacheDirectory(const FileSpec &dir_spec) {
return m_collection_sp->SetPropertyAtIndex(ePropertyModuleCacheDirectory,
dir_spec);
}
void PlatformProperties::SetDefaultModuleCacheDirectory(
const FileSpec &dir_spec) {
auto f_spec_opt = m_collection_sp->GetPropertyAtIndexAsOptionValueFileSpec(
ePropertyModuleCacheDirectory);
assert(f_spec_opt);
f_spec_opt->SetDefaultValue(dir_spec);
}
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-08 22:40:15 +00:00
/// Get the native host platform plug-in.
///
/// There should only be one of these for each host that LLDB runs
/// upon that should be statically compiled in and registered using
/// preprocessor macros or other similar build mechanisms.
///
/// This platform will be used as the default platform when launching
/// or attaching to processes unless another platform is specified.
PlatformSP Platform::GetHostPlatform() { return GetHostPlatformSP(); }
void Platform::Initialize() {}
void Platform::Terminate() {}
PlatformProperties &Platform::GetGlobalPlatformProperties() {
static PlatformProperties g_settings;
return g_settings;
}
void Platform::SetHostPlatform(const lldb::PlatformSP &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-08 22:40:15 +00:00
// The native platform should use its static void Platform::Initialize()
// function to register itself as the native platform.
GetHostPlatformSP() = 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-08 22:40:15 +00:00
}
Status Platform::GetFileWithUUID(const FileSpec &platform_file,
const UUID *uuid_ptr, FileSpec &local_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-08 22:40:15 +00:00
// Default to the local case
local_file = platform_file;
return Status();
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-08 22:40:15 +00:00
}
FileSpecList
Platform::LocateExecutableScriptingResources(Target *target, Module &module,
Stream &feedback_stream) {
return FileSpecList();
}
[lldb] GetSharedModule: Collect old modules in SmallVector The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156
2020-10-30 15:12:10 -04:00
Status Platform::GetSharedModule(
const ModuleSpec &module_spec, Process *process, ModuleSP &module_sp,
const FileSpecList *module_search_paths_ptr,
llvm::SmallVectorImpl<lldb::ModuleSP> *old_modules, bool *did_create_ptr) {
if (IsHost())
[lldb] GetSharedModule: Collect old modules in SmallVector The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156
2020-10-30 15:12:10 -04:00
return ModuleList::GetSharedModule(module_spec, module_sp,
module_search_paths_ptr, old_modules,
did_create_ptr, false);
// Module resolver lambda.
auto resolver = [&](const ModuleSpec &spec) {
Status error(eErrorTypeGeneric);
ModuleSpec resolved_spec;
// Check if we have sysroot set.
if (!m_sdk_sysroot.empty()) {
// Prepend sysroot to module spec.
resolved_spec = spec;
resolved_spec.GetFileSpec().PrependPathComponent(m_sdk_sysroot);
// Try to get shared module with resolved spec.
[lldb] GetSharedModule: Collect old modules in SmallVector The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156
2020-10-30 15:12:10 -04:00
error = ModuleList::GetSharedModule(resolved_spec, module_sp,
module_search_paths_ptr, old_modules,
did_create_ptr, false);
}
// If we don't have sysroot or it didn't work then
// try original module spec.
if (!error.Success()) {
resolved_spec = spec;
[lldb] GetSharedModule: Collect old modules in SmallVector The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156
2020-10-30 15:12:10 -04:00
error = ModuleList::GetSharedModule(resolved_spec, module_sp,
module_search_paths_ptr, old_modules,
did_create_ptr, false);
}
if (error.Success() && module_sp)
module_sp->SetPlatformFileSpec(resolved_spec.GetFileSpec());
return error;
};
return GetRemoteSharedModule(module_spec, process, module_sp, resolver,
did_create_ptr);
}
bool Platform::GetModuleSpec(const FileSpec &module_file_spec,
const ArchSpec &arch, ModuleSpec &module_spec) {
ModuleSpecList module_specs;
if (ObjectFile::GetModuleSpecifications(module_file_spec, 0, 0,
module_specs) == 0)
return false;
ModuleSpec matched_module_spec;
return module_specs.FindMatchingModuleSpec(ModuleSpec(module_file_spec, arch),
module_spec);
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-30 18:16:51 +00:00
}
PlatformSP Platform::Create(llvm::StringRef name) {
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-08 22:40:15 +00:00
lldb::PlatformSP platform_sp;
if (name == GetHostPlatformName())
return GetHostPlatform();
if (PlatformCreateInstance create_callback =
PluginManager::GetPlatformCreateCallbackForPluginName(name))
return create_callback(true, nullptr);
return nullptr;
}
ArchSpec Platform::GetAugmentedArchSpec(Platform *platform, llvm::StringRef triple) {
if (platform)
return platform->GetAugmentedArchSpec(triple);
return HostInfo::GetAugmentedArchSpec(triple);
}
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-08 22:40:15 +00:00
/// Default Constructor
Platform::Platform(bool is_host)
: m_is_host(is_host), m_os_version_set_while_connected(false),
m_system_arch_set_while_connected(false), m_max_uid_name_len(0),
m_max_gid_name_len(0), m_supports_rsync(false), m_rsync_opts(),
m_rsync_prefix(), m_supports_ssh(false), m_ssh_opts(),
m_ignores_remote_hostname(false), m_trap_handlers(),
m_calculated_trap_handlers(false),
m_module_cache(std::make_unique<ModuleCache>()) {
Log *log = GetLog(LLDBLog::Object);
LLDB_LOGF(log, "%p Platform::Platform()", static_cast<void *>(this));
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-08 22:40:15 +00:00
}
Platform::~Platform() = default;
void Platform::GetStatus(Stream &strm) {
strm.Format(" Platform: {0}\n", GetPluginName());
ArchSpec arch(GetSystemArchitecture());
if (arch.IsValid()) {
if (!arch.GetTriple().str().empty()) {
strm.Printf(" Triple: ");
arch.DumpTriple(strm.AsRawOstream());
strm.EOL();
}
}
llvm::VersionTuple os_version = GetOSVersion();
if (!os_version.empty()) {
strm.Format("OS Version: {0}", os_version.getAsString());
if (std::optional<std::string> s = GetOSBuildString())
strm.Format(" ({0})", *s);
strm.EOL();
}
if (IsHost()) {
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-30 18:16:51 +00:00
strm.Printf(" Hostname: %s\n", GetHostname());
} else {
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-30 18:16:51 +00:00
const bool is_connected = IsConnected();
if (is_connected)
strm.Printf(" Hostname: %s\n", GetHostname());
strm.Printf(" Connected: %s\n", is_connected ? "yes" : "no");
}
if (const std::string &sdk_root = GetSDKRootDirectory(); !sdk_root.empty())
strm.Format(" Sysroot: {0}\n", sdk_root);
if (GetWorkingDirectory()) {
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
strm.Printf("WorkingDir: %s\n", GetWorkingDirectory().GetPath().c_str());
}
if (!IsConnected())
return;
std::string specific_info(GetPlatformSpecificConnectionInformation());
if (!specific_info.empty())
strm.Printf("Platform-specific connection: %s\n", specific_info.c_str());
if (std::optional<std::string> s = GetOSKernelDescription())
strm.Format(" Kernel: {0}\n", *s);
}
llvm::VersionTuple Platform::GetOSVersion(Process *process) {
std::lock_guard<std::mutex> guard(m_mutex);
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 01:12:21 +00:00
if (IsHost()) {
if (m_os_version.empty()) {
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 01:12:21 +00:00
// We have a local host platform
m_os_version = HostInfo::GetOSVersion();
m_os_version_set_while_connected = !m_os_version.empty();
}
} else {
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 01:12:21 +00:00
// We have a remote platform. We can only fetch the remote
// OS version if we are connected, and we don't want to do it
// more than once.
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-30 18:16:51 +00:00
const bool is_connected = IsConnected();
bool fetch = false;
if (!m_os_version.empty()) {
// We have valid OS version info, check to make sure it wasn't manually
// set prior to connecting. If it was manually set prior to connecting,
// then lets fetch the actual OS version info if we are now connected.
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-30 18:16:51 +00:00
if (is_connected && !m_os_version_set_while_connected)
fetch = true;
} else {
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-30 18:16:51 +00:00
// We don't have valid OS version info, fetch it if we are connected
fetch = is_connected;
}
if (fetch)
m_os_version_set_while_connected = GetRemoteOSVersion();
}
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 01:12:21 +00:00
if (!m_os_version.empty())
return m_os_version;
if (process) {
// Check with the process in case it can answer the question if a process
// was provided
return process->GetHostOSVersion();
}
return llvm::VersionTuple();
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 01:12:21 +00:00
}
std::optional<std::string> Platform::GetOSBuildString() {
if (IsHost())
return HostInfo::GetOSBuildString();
return GetRemoteOSBuildString();
}
std::optional<std::string> Platform::GetOSKernelDescription() {
if (IsHost())
return HostInfo::GetOSKernelDescription();
return GetRemoteOSKernelDescription();
}
void Platform::AddClangModuleCompilationOptions(
Target *target, std::vector<std::string> &options) {
std::vector<std::string> default_compilation_options = {
"-x", "c++", "-Xclang", "-nostdsysteminc", "-Xclang", "-nostdsysteminc"};
options.insert(options.end(), default_compilation_options.begin(),
default_compilation_options.end());
}
FileSpec Platform::GetWorkingDirectory() {
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 01:12:21 +00:00
if (IsHost()) {
llvm::SmallString<64> cwd;
if (llvm::sys::fs::current_path(cwd))
return {};
else {
FileSpec file_spec(cwd);
FileSystem::Instance().Resolve(file_spec);
return file_spec;
}
} else {
if (!m_working_dir)
m_working_dir = GetRemoteWorkingDirectory();
return m_working_dir;
}
}
struct RecurseCopyBaton {
const FileSpec &dst;
Platform *platform_ptr;
Status error;
};
static FileSystem::EnumerateDirectoryResult
RecurseCopy_Callback(void *baton, llvm::sys::fs::file_type ft,
llvm::StringRef path) {
RecurseCopyBaton *rc_baton = (RecurseCopyBaton *)baton;
FileSpec src(path);
namespace fs = llvm::sys::fs;
switch (ft) {
case fs::file_type::fifo_file:
case fs::file_type::socket_file:
// we have no way to copy pipes and sockets - ignore them and continue
return FileSystem::eEnumerateDirectoryResultNext;
break;
case fs::file_type::directory_file: {
// make the new directory and get in there
FileSpec dst_dir = rc_baton->dst;
if (!dst_dir.GetFilename())
dst_dir.SetFilename(src.GetFilename());
Status error = rc_baton->platform_ptr->MakeDirectory(
dst_dir, lldb::eFilePermissionsDirectoryDefault);
if (error.Fail()) {
rc_baton->error = Status::FromErrorStringWithFormatv(
"unable to setup directory {0} on remote end", dst_dir.GetPath());
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
}
// now recurse
std::string src_dir_path(src.GetPath());
// Make a filespec that only fills in the directory of a FileSpec so when
// we enumerate we can quickly fill in the filename for dst copies
FileSpec recurse_dst;
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
recurse_dst.SetDirectory(dst_dir.GetPathAsConstString());
RecurseCopyBaton rc_baton2 = {recurse_dst, rc_baton->platform_ptr,
Status()};
FileSystem::Instance().EnumerateDirectory(src_dir_path, true, true, true,
RecurseCopy_Callback, &rc_baton2);
if (rc_baton2.error.Fail()) {
rc_baton->error = Status::FromErrorString(rc_baton2.error.AsCString());
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
}
return FileSystem::eEnumerateDirectoryResultNext;
} break;
case fs::file_type::symlink_file: {
// copy the file and keep going
FileSpec dst_file = rc_baton->dst;
if (!dst_file.GetFilename())
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
dst_file.SetFilename(src.GetFilename());
FileSpec src_resolved;
rc_baton->error = FileSystem::Instance().Readlink(src, src_resolved);
if (rc_baton->error.Fail())
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
rc_baton->error =
rc_baton->platform_ptr->CreateSymlink(dst_file, src_resolved);
if (rc_baton->error.Fail())
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
return FileSystem::eEnumerateDirectoryResultNext;
} break;
case fs::file_type::regular_file: {
// copy the file and keep going
FileSpec dst_file = rc_baton->dst;
if (!dst_file.GetFilename())
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
dst_file.SetFilename(src.GetFilename());
Status err = rc_baton->platform_ptr->PutFile(src, dst_file);
if (err.Fail()) {
rc_baton->error = Status::FromErrorString(err.AsCString());
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
}
return FileSystem::eEnumerateDirectoryResultNext;
} break;
default:
rc_baton->error = Status::FromErrorStringWithFormat(
"invalid file detected during copy: %s", src.GetPath().c_str());
return FileSystem::eEnumerateDirectoryResultQuit; // got an error, bail out
break;
}
llvm_unreachable("Unhandled file_type!");
}
Status Platform::Install(const FileSpec &src, const FileSpec &dst) {
Status error;
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "Platform::Install (src='%s', dst='%s')",
src.GetPath().c_str(), dst.GetPath().c_str());
FileSpec fixed_dst(dst);
if (!fixed_dst.GetFilename())
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
fixed_dst.SetFilename(src.GetFilename());
FileSpec working_dir = GetWorkingDirectory();
if (dst) {
if (dst.GetDirectory()) {
const char first_dst_dir_char = dst.GetDirectory().GetCString()[0];
if (first_dst_dir_char == '/' || first_dst_dir_char == '\\') {
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
fixed_dst.SetDirectory(dst.GetDirectory());
}
// If the fixed destination file doesn't have a directory yet, then we
// must have a relative path. We will resolve this relative path against
// the platform's working directory
if (!fixed_dst.GetDirectory()) {
FileSpec relative_spec;
std::string path;
if (working_dir) {
relative_spec = working_dir;
relative_spec.AppendPathComponent(dst.GetPath());
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
fixed_dst.SetDirectory(relative_spec.GetDirectory());
} else {
error = Status::FromErrorStringWithFormat(
"platform working directory must be valid for relative path '%s'",
dst.GetPath().c_str());
return error;
}
}
} else {
if (working_dir) {
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
fixed_dst.SetDirectory(working_dir.GetPathAsConstString());
} else {
error = Status::FromErrorStringWithFormat(
"platform working directory must be valid for relative path '%s'",
dst.GetPath().c_str());
return error;
}
}
} else {
if (working_dir) {
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
fixed_dst.SetDirectory(working_dir.GetPathAsConstString());
} else {
error =
Status::FromErrorString("platform working directory must be valid "
"when destination directory is empty");
return error;
}
}
LLDB_LOGF(log, "Platform::Install (src='%s', dst='%s') fixed_dst='%s'",
src.GetPath().c_str(), dst.GetPath().c_str(),
fixed_dst.GetPath().c_str());
if (GetSupportsRSync()) {
error = PutFile(src, dst);
} else {
namespace fs = llvm::sys::fs;
switch (fs::get_file_type(src.GetPath(), false)) {
case fs::file_type::directory_file: {
llvm::sys::fs::remove(fixed_dst.GetPath());
uint32_t permissions = FileSystem::Instance().GetPermissions(src);
if (permissions == 0)
permissions = eFilePermissionsDirectoryDefault;
error = MakeDirectory(fixed_dst, permissions);
if (error.Success()) {
// Make a filespec that only fills in the directory of a FileSpec so
// when we enumerate we can quickly fill in the filename for dst copies
FileSpec recurse_dst;
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
recurse_dst.SetDirectory(fixed_dst.GetPathAsConstString());
std::string src_dir_path(src.GetPath());
RecurseCopyBaton baton = {recurse_dst, this, Status()};
FileSystem::Instance().EnumerateDirectory(
src_dir_path, true, true, true, RecurseCopy_Callback, &baton);
return std::move(baton.error);
}
} break;
case fs::file_type::regular_file:
llvm::sys::fs::remove(fixed_dst.GetPath());
error = PutFile(src, fixed_dst);
break;
case fs::file_type::symlink_file: {
llvm::sys::fs::remove(fixed_dst.GetPath());
FileSpec src_resolved;
error = FileSystem::Instance().Readlink(src, src_resolved);
if (error.Success())
error = CreateSymlink(dst, src_resolved);
} break;
case fs::file_type::fifo_file:
error = Status::FromErrorString("platform install doesn't handle pipes");
break;
case fs::file_type::socket_file:
error =
Status::FromErrorString("platform install doesn't handle sockets");
break;
default:
error = Status::FromErrorString(
"platform install doesn't handle non file or directory items");
break;
}
}
return error;
}
bool Platform::SetWorkingDirectory(const FileSpec &file_spec) {
if (IsHost()) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOG(log, "{0}", file_spec);
if (std::error_code ec = llvm::sys::fs::set_current_path(file_spec.GetPath())) {
LLDB_LOG(log, "error: {0}", ec.message());
return false;
}
return true;
} else {
m_working_dir.Clear();
return SetRemoteWorkingDirectory(file_spec);
}
}
Status Platform::MakeDirectory(const FileSpec &file_spec,
uint32_t permissions) {
if (IsHost())
return llvm::sys::fs::create_directory(file_spec.GetPath(), permissions);
else {
Status error;
return Status::FromErrorStringWithFormatv(
"remote platform {0} doesn't support {1}", GetPluginName(),
LLVM_PRETTY_FUNCTION);
return error;
}
}
Status Platform::GetFilePermissions(const FileSpec &file_spec,
uint32_t &file_permissions) {
if (IsHost()) {
auto Value = llvm::sys::fs::getPermissions(file_spec.GetPath());
if (Value)
file_permissions = Value.get();
return Status(Value.getError());
} else {
Status error;
return Status::FromErrorStringWithFormatv(
"remote platform {0} doesn't support {1}", GetPluginName(),
LLVM_PRETTY_FUNCTION);
return error;
}
}
Status Platform::SetFilePermissions(const FileSpec &file_spec,
uint32_t file_permissions) {
if (IsHost()) {
auto Perms = static_cast<llvm::sys::fs::perms>(file_permissions);
return llvm::sys::fs::setPermissions(file_spec.GetPath(), Perms);
} else {
Status error;
return Status::FromErrorStringWithFormatv(
"remote platform {0} doesn't support {1}", GetPluginName(),
LLVM_PRETTY_FUNCTION);
return error;
}
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 05:54:46 +00:00
}
user_id_t Platform::OpenFile(const FileSpec &file_spec,
File::OpenOptions flags, uint32_t mode,
Status &error) {
if (IsHost())
return FileCache::GetInstance().OpenFile(file_spec, flags, mode, error);
return UINT64_MAX;
}
bool Platform::CloseFile(user_id_t fd, Status &error) {
if (IsHost())
return FileCache::GetInstance().CloseFile(fd, error);
return false;
}
user_id_t Platform::GetFileSize(const FileSpec &file_spec) {
if (!IsHost())
return UINT64_MAX;
uint64_t Size;
if (llvm::sys::fs::file_size(file_spec.GetPath(), Size))
return 0;
return Size;
}
uint64_t Platform::ReadFile(lldb::user_id_t fd, uint64_t offset, void *dst,
uint64_t dst_len, Status &error) {
if (IsHost())
return FileCache::GetInstance().ReadFile(fd, offset, dst, dst_len, error);
error = Status::FromErrorStringWithFormatv(
"Platform::ReadFile() is not supported in the {0} platform",
GetPluginName());
return -1;
}
uint64_t Platform::WriteFile(lldb::user_id_t fd, uint64_t offset,
const void *src, uint64_t src_len, Status &error) {
if (IsHost())
return FileCache::GetInstance().WriteFile(fd, offset, src, src_len, error);
error = Status::FromErrorStringWithFormatv(
"Platform::WriteFile() is not supported in the {0} platform",
GetPluginName());
return -1;
}
UserIDResolver &Platform::GetUserIDResolver() {
if (IsHost())
return HostInfo::GetUserIDResolver();
return UserIDResolver::GetNoopResolver();
}
const char *Platform::GetHostname() {
if (IsHost())
return "127.0.0.1";
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-30 18:16:51 +00:00
if (m_hostname.empty())
return nullptr;
return m_hostname.c_str();
}
ConstString Platform::GetFullNameForDylib(ConstString basename) {
return basename;
}
bool Platform::SetRemoteWorkingDirectory(const FileSpec &working_dir) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "Platform::SetRemoteWorkingDirectory('%s')",
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
working_dir.GetPath().c_str());
m_working_dir = working_dir;
return true;
}
bool Platform::SetOSVersion(llvm::VersionTuple version) {
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 01:12:21 +00:00
if (IsHost()) {
// We don't need anyone setting the OS version for the host platform, we
// should be able to figure it out by calling HostInfo::GetOSVersion(...).
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 01:12:21 +00:00
return false;
} else {
// We have a remote platform, allow setting the target OS version if we
// aren't connected, since if we are connected, we should be able to
// request the remote OS version from the connected platform.
if (IsConnected())
return false;
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-08 22:40:15 +00:00
else {
// We aren't connected and we might want to set the OS version ahead of
// time before we connect so we can peruse files and use a local SDK or
// PDK cache of support files to disassemble or do other things.
m_os_version = version;
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-08 22:40:15 +00:00
return true;
}
}
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-08 22:40:15 +00:00
return false;
}
Status
Platform::ResolveExecutable(const ModuleSpec &module_spec,
lldb::ModuleSP &exe_module_sp,
const FileSpecList *module_search_paths_ptr) {
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
// We may connect to a process and use the provided executable (Don't use
// local $PATH).
ModuleSpec resolved_module_spec(module_spec);
// Resolve any executable within a bundle on MacOSX
Host::ResolveExecutableInBundle(resolved_module_spec.GetFileSpec());
if (!FileSystem::Instance().Exists(resolved_module_spec.GetFileSpec()) &&
!module_spec.GetUUID().IsValid())
return Status::FromErrorStringWithFormatv(
"'{0}' does not exist", resolved_module_spec.GetFileSpec());
if (resolved_module_spec.GetArchitecture().IsValid() ||
resolved_module_spec.GetUUID().IsValid()) {
Status error =
ModuleList::GetSharedModule(resolved_module_spec, exe_module_sp,
module_search_paths_ptr, nullptr, nullptr);
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
if (exe_module_sp && exe_module_sp->GetObjectFile())
return error;
exe_module_sp.reset();
}
// No valid architecture was specified or the exact arch wasn't found.
// Ask the platform for the architectures that we should be using (in the
// correct order) and see if we can find a match that way.
StreamString arch_names;
llvm::ListSeparator LS;
ArchSpec process_host_arch;
Status error;
for (const ArchSpec &arch : GetSupportedArchitectures(process_host_arch)) {
resolved_module_spec.GetArchitecture() = arch;
error =
ModuleList::GetSharedModule(resolved_module_spec, exe_module_sp,
module_search_paths_ptr, nullptr, nullptr);
if (error.Success()) {
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
if (exe_module_sp && exe_module_sp->GetObjectFile())
break;
error = Status::FromErrorString("no exe object file");
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
}
arch_names << LS << arch.GetArchitectureName();
}
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
if (exe_module_sp && error.Success())
return {};
if (!FileSystem::Instance().Readable(resolved_module_spec.GetFileSpec()))
return Status::FromErrorStringWithFormatv(
"'{0}' is not readable", resolved_module_spec.GetFileSpec());
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
if (!ObjectFile::IsObjectFile(resolved_module_spec.GetFileSpec()))
return Status::FromErrorStringWithFormatv(
"'{0}' is not a valid executable", resolved_module_spec.GetFileSpec());
return Status::FromErrorStringWithFormatv(
"'{0}' doesn't contain any '{1}' platform architectures: {2}",
resolved_module_spec.GetFileSpec(), GetPluginName(),
arch_names.GetData());
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
}
Status Platform::ResolveSymbolFile(Target &target, const ModuleSpec &sym_spec,
FileSpec &sym_file) {
Status error;
if (FileSystem::Instance().Exists(sym_spec.GetSymbolFileSpec()))
sym_file = sym_spec.GetSymbolFileSpec();
else
error = Status::FromErrorString("unable to resolve symbol file");
return error;
}
bool Platform::ResolveRemotePath(const FileSpec &platform_path,
FileSpec &resolved_platform_path) {
resolved_platform_path = platform_path;
FileSystem::Instance().Resolve(resolved_platform_path);
return true;
}
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 01:12:21 +00:00
const ArchSpec &Platform::GetSystemArchitecture() {
if (IsHost()) {
if (!m_system_arch.IsValid()) {
// We have a local host platform
m_system_arch = HostInfo::GetArchitecture();
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 01:12:21 +00:00
m_system_arch_set_while_connected = m_system_arch.IsValid();
}
} else {
// We have a remote platform. We can only fetch the remote system
// architecture if we are connected, and we don't want to do it more than
// once.
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 01:12:21 +00:00
const bool is_connected = IsConnected();
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 01:12:21 +00:00
bool fetch = false;
if (m_system_arch.IsValid()) {
// We have valid OS version info, check to make sure it wasn't manually
// set prior to connecting. If it was manually set prior to connecting,
// then lets fetch the actual OS version info if we are now connected.
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 01:12:21 +00:00
if (is_connected && !m_system_arch_set_while_connected)
fetch = true;
} else {
// We don't have valid OS version info, fetch it if we are connected
fetch = is_connected;
}
if (fetch) {
m_system_arch = GetRemoteSystemArchitecture();
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 01:12:21 +00:00
m_system_arch_set_while_connected = m_system_arch.IsValid();
}
}
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 01:12:21 +00:00
return m_system_arch;
}
ArchSpec Platform::GetAugmentedArchSpec(llvm::StringRef triple) {
if (triple.empty())
return ArchSpec();
llvm::Triple normalized_triple(llvm::Triple::normalize(triple));
if (!ArchSpec::ContainsOnlyArch(normalized_triple))
return ArchSpec(triple);
if (auto kind = HostInfo::ParseArchitectureKind(triple))
return HostInfo::GetArchitecture(*kind);
ArchSpec compatible_arch;
ArchSpec raw_arch(triple);
if (!IsCompatibleArchitecture(raw_arch, {}, ArchSpec::CompatibleMatch,
&compatible_arch))
return raw_arch;
if (!compatible_arch.IsValid())
return ArchSpec(normalized_triple);
const llvm::Triple &compatible_triple = compatible_arch.GetTriple();
if (normalized_triple.getVendorName().empty())
normalized_triple.setVendor(compatible_triple.getVendor());
if (normalized_triple.getOSName().empty())
normalized_triple.setOS(compatible_triple.getOS());
if (normalized_triple.getEnvironmentName().empty())
normalized_triple.setEnvironment(compatible_triple.getEnvironment());
return ArchSpec(normalized_triple);
}
Status Platform::ConnectRemote(Args &args) {
Status error;
if (IsHost())
return Status::FromErrorStringWithFormatv(
"The currently selected platform ({0}) is "
"the host platform and is always connected.",
GetPluginName());
else
return Status::FromErrorStringWithFormatv(
"Platform::ConnectRemote() is not supported by {0}", GetPluginName());
return error;
}
Status Platform::DisconnectRemote() {
Status error;
if (IsHost())
return Status::FromErrorStringWithFormatv(
"The currently selected platform ({0}) is "
"the host platform and is always connected.",
GetPluginName());
else
return Status::FromErrorStringWithFormatv(
"Platform::DisconnectRemote() is not supported by {0}",
GetPluginName());
return error;
}
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 05:54:46 +00:00
bool Platform::GetProcessInfo(lldb::pid_t pid,
ProcessInstanceInfo &process_info) {
// Take care of the host case so that each subclass can just call this
// function to get the host functionality.
if (IsHost())
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-30 18:16:51 +00:00
return Host::GetProcessInfo(pid, process_info);
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 01:12:21 +00:00
return false;
}
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 05:54:46 +00:00
uint32_t Platform::FindProcesses(const ProcessInstanceInfoMatch &match_info,
ProcessInstanceInfoList &process_infos) {
// Take care of the host case so that each subclass can just call this
// function to get the host functionality.
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-30 18:16:51 +00:00
uint32_t match_count = 0;
if (IsHost())
match_count = Host::FindProcesses(match_info, process_infos);
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-30 18:16:51 +00:00
return match_count;
}
ProcessInstanceInfoList Platform::GetAllProcesses() {
ProcessInstanceInfoList processes;
ProcessInstanceInfoMatch match;
assert(match.MatchAllProcesses());
FindProcesses(match, processes);
return processes;
}
Status Platform::LaunchProcess(ProcessLaunchInfo &launch_info) {
Status error;
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "Platform::%s()", __FUNCTION__);
// Take care of the host case so that each subclass can just call this
// function to get the host functionality.
if (IsHost()) {
if (::getenv("LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY"))
launch_info.GetFlags().Set(eLaunchFlagLaunchInTTY);
if (launch_info.GetFlags().Test(eLaunchFlagLaunchInShell)) {
const bool will_debug = launch_info.GetFlags().Test(eLaunchFlagDebug);
const bool first_arg_is_full_shell_command = false;
uint32_t num_resumes = GetResumeCountForLaunchInfo(launch_info);
if (log) {
const FileSpec &shell = launch_info.GetShell();
std::string shell_str = (shell) ? shell.GetPath() : "<null>";
LLDB_LOGF(log,
"Platform::%s GetResumeCountForLaunchInfo() returned %" PRIu32
", shell is '%s'",
__FUNCTION__, num_resumes, shell_str.c_str());
}
if (!launch_info.ConvertArgumentsForLaunchingInShell(
error, will_debug, first_arg_is_full_shell_command, num_resumes))
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-08 22:40:15 +00:00
return error;
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 05:54:46 +00:00
} else if (launch_info.GetFlags().Test(eLaunchFlagShellExpandArguments)) {
error = ShellExpandArguments(launch_info);
if (error.Fail()) {
error = Status::FromErrorStringWithFormat(
"shell expansion failed (reason: %s). "
"consider launching with 'process "
"launch'.",
error.AsCString("unknown"));
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-08 22:40:15 +00:00
return error;
}
}
LLDB_LOGF(log, "Platform::%s final launch_info resume count: %" PRIu32,
__FUNCTION__, launch_info.GetResumeCount());
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 05:54:46 +00:00
error = Host::LaunchProcess(launch_info);
} else
error = Status::FromErrorString(
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 05:54:46 +00:00
"base lldb_private::Platform class can't launch remote processes");
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-08 22:40:15 +00:00
return error;
}
Status Platform::ShellExpandArguments(ProcessLaunchInfo &launch_info) {
if (IsHost())
return Host::ShellExpandArguments(launch_info);
return Status::FromErrorString(
"base lldb_private::Platform class can't expand arguments");
}
Status Platform::KillProcess(const lldb::pid_t pid) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "Platform::%s, pid %" PRIu64, __FUNCTION__, pid);
if (!IsHost()) {
return Status::FromErrorString(
"base lldb_private::Platform class can't kill remote processes");
}
Host::Kill(pid, SIGKILL);
return Status();
}
lldb::ProcessSP Platform::DebugProcess(ProcessLaunchInfo &launch_info,
Debugger &debugger, Target &target,
Status &error) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOG(log, "target = {0}", &target);
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 05:54:46 +00:00
ProcessSP process_sp;
// Make sure we stop at the entry point
launch_info.GetFlags().Set(eLaunchFlagDebug);
// We always launch the process we are going to debug in a separate process
// group, since then we can handle ^C interrupts ourselves w/o having to
// worry about the target getting them as well.
launch_info.SetLaunchInSeparateProcessGroup(true);
// Allow any StructuredData process-bound plugins to adjust the launch info
// if needed
size_t i = 0;
bool iteration_complete = false;
// Note iteration can't simply go until a nullptr callback is returned, as it
// is valid for a plugin to not supply a filter.
auto get_filter_func = PluginManager::GetStructuredDataFilterCallbackAtIndex;
for (auto filter_callback = get_filter_func(i, iteration_complete);
!iteration_complete;
filter_callback = get_filter_func(++i, iteration_complete)) {
if (filter_callback) {
// Give this ProcessLaunchInfo filter a chance to adjust the launch info.
error = (*filter_callback)(launch_info, &target);
if (!error.Success()) {
LLDB_LOGF(log,
"Platform::%s() StructuredDataPlugin launch "
"filter failed.",
__FUNCTION__);
return process_sp;
}
}
}
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 05:54:46 +00:00
error = LaunchProcess(launch_info);
if (error.Success()) {
LLDB_LOGF(log,
"Platform::%s LaunchProcess() call succeeded (pid=%" PRIu64 ")",
__FUNCTION__, launch_info.GetProcessID());
if (launch_info.GetProcessID() != LLDB_INVALID_PROCESS_ID) {
ProcessAttachInfo attach_info(launch_info);
process_sp = Attach(attach_info, debugger, &target, error);
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 05:54:46 +00:00
if (process_sp) {
LLDB_LOG(log, "Attach() succeeded, Process plugin: {0}",
process_sp->GetPluginName());
launch_info.SetHijackListener(attach_info.GetHijackListener());
// Since we attached to the process, it will think it needs to detach
// if the process object just goes away without an explicit call to
// Process::Kill() or Process::Detach(), so let it know to kill the
// process if this happens.
process_sp->SetShouldDetach(false);
// If we didn't have any file actions, the pseudo terminal might have
// been used where the secondary side was given as the file to open for
// stdin/out/err after we have already opened the primary so we can
// read/write stdin/out/err.
int pty_fd = launch_info.GetPTY().ReleasePrimaryFileDescriptor();
if (pty_fd != PseudoTerminal::invalid_fd) {
process_sp->SetSTDIOFileDescriptor(pty_fd);
}
} else {
LLDB_LOGF(log, "Platform::%s Attach() failed: %s", __FUNCTION__,
error.AsCString());
}
} else {
LLDB_LOGF(log,
"Platform::%s LaunchProcess() returned launch_info with "
"invalid process id",
__FUNCTION__);
}
} else {
LLDB_LOGF(log, "Platform::%s LaunchProcess() failed: %s", __FUNCTION__,
error.AsCString());
}
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 05:54:46 +00:00
return process_sp;
}
std::vector<ArchSpec>
Platform::CreateArchList(llvm::ArrayRef<llvm::Triple::ArchType> archs,
llvm::Triple::OSType os) {
std::vector<ArchSpec> list;
for(auto arch : archs) {
llvm::Triple triple;
triple.setArch(arch);
triple.setOS(os);
list.push_back(ArchSpec(triple));
}
return list;
}
/// Lets a platform answer if it is compatible with a given
/// architecture and the target triple contained within.
bool Platform::IsCompatibleArchitecture(const ArchSpec &arch,
const ArchSpec &process_host_arch,
ArchSpec::MatchType match,
ArchSpec *compatible_arch_ptr) {
// If the architecture is invalid, we must answer true...
if (arch.IsValid()) {
ArchSpec platform_arch;
for (const ArchSpec &platform_arch :
GetSupportedArchitectures(process_host_arch)) {
if (arch.IsMatch(platform_arch, match)) {
if (compatible_arch_ptr)
*compatible_arch_ptr = platform_arch;
return true;
}
}
}
if (compatible_arch_ptr)
compatible_arch_ptr->Clear();
return false;
}
Status Platform::PutFile(const FileSpec &source, const FileSpec &destination,
uint32_t uid, uint32_t gid) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "[PutFile] Using block by block transfer....\n");
auto source_open_options =
File::eOpenOptionReadOnly | File::eOpenOptionCloseOnExec;
namespace fs = llvm::sys::fs;
if (fs::is_symlink_file(source.GetPath()))
source_open_options |= File::eOpenOptionDontFollowSymlinks;
auto source_file = FileSystem::Instance().Open(source, source_open_options,
lldb::eFilePermissionsUserRW);
if (!source_file)
return Status::FromError(source_file.takeError());
Status error;
bool requires_upload = true;
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
llvm::ErrorOr<llvm::MD5::MD5Result> remote_md5 = CalculateMD5(destination);
if (std::error_code ec = remote_md5.getError()) {
LLDB_LOG(log, "[PutFile] couldn't get md5 sum of destination: {0}",
ec.message());
} else {
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
llvm::ErrorOr<llvm::MD5::MD5Result> local_md5 =
llvm::sys::fs::md5_contents(source.GetPath());
if (std::error_code ec = local_md5.getError()) {
LLDB_LOG(log, "[PutFile] couldn't get md5 sum of source: {0}",
ec.message());
} else {
LLDB_LOGF(log, "[PutFile] destination md5: %016" PRIx64 "%016" PRIx64,
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
remote_md5->high(), remote_md5->low());
LLDB_LOGF(log, "[PutFile] local md5: %016" PRIx64 "%016" PRIx64,
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
local_md5->high(), local_md5->low());
requires_upload = *remote_md5 != *local_md5;
}
}
if (!requires_upload) {
LLDB_LOGF(log, "[PutFile] skipping PutFile because md5sums match");
return error;
}
uint32_t permissions = source_file.get()->GetPermissions(error);
if (permissions == 0)
permissions = lldb::eFilePermissionsUserRWX;
lldb::user_id_t dest_file = OpenFile(
destination, File::eOpenOptionCanCreate | File::eOpenOptionWriteOnly |
File::eOpenOptionTruncate | File::eOpenOptionCloseOnExec,
permissions, error);
LLDB_LOGF(log, "dest_file = %" PRIu64 "\n", dest_file);
if (error.Fail())
return error;
if (dest_file == UINT64_MAX)
return Status::FromErrorString("unable to open target file");
lldb::WritableDataBufferSP buffer_sp(new DataBufferHeap(1024 * 16, 0));
uint64_t offset = 0;
for (;;) {
size_t bytes_read = buffer_sp->GetByteSize();
error = source_file.get()->Read(buffer_sp->GetBytes(), bytes_read);
if (error.Fail() || bytes_read == 0)
break;
const uint64_t bytes_written =
WriteFile(dest_file, offset, buffer_sp->GetBytes(), bytes_read, error);
if (error.Fail())
break;
offset += bytes_written;
if (bytes_written != bytes_read) {
// We didn't write the correct number of bytes, so adjust the file
// position in the source file we are reading from...
source_file.get()->SeekFromStart(offset);
}
}
CloseFile(dest_file, error);
if (uid == UINT32_MAX && gid == UINT32_MAX)
return error;
// TODO: ChownFile?
return error;
}
Status Platform::GetFile(const FileSpec &source, const FileSpec &destination) {
return Status::FromErrorString("unimplemented");
}
Status
Platform::CreateSymlink(const FileSpec &src, // The name of the link is in src
const FileSpec &dst) // The symlink points to dst
{
if (IsHost())
return FileSystem::Instance().Symlink(src, dst);
return Status::FromErrorString("unimplemented");
}
bool Platform::GetFileExists(const lldb_private::FileSpec &file_spec) {
if (IsHost())
return FileSystem::Instance().Exists(file_spec);
return false;
}
Status Platform::Unlink(const FileSpec &path) {
if (IsHost())
return llvm::sys::fs::remove(path.GetPath());
return Status::FromErrorString("unimplemented");
}
MmapArgList Platform::GetMmapArgumentList(const ArchSpec &arch, addr_t addr,
addr_t length, unsigned prot,
unsigned flags, addr_t fd,
addr_t offset) {
uint64_t flags_platform = 0;
if (flags & eMmapFlagsPrivate)
flags_platform |= MAP_PRIVATE;
if (flags & eMmapFlagsAnon)
flags_platform |= MAP_ANON;
MmapArgList args({addr, length, prot, flags_platform, fd, offset});
return args;
}
lldb_private::Status Platform::RunShellCommand(
llvm::StringRef command,
const FileSpec &
working_dir, // Pass empty FileSpec to use the current working directory
int *status_ptr, // Pass nullptr if you don't want the process exit status
int *signo_ptr, // Pass nullptr if you don't want the signal that caused the
// process to exit
std::string
*command_output, // Pass nullptr if you don't want the command output
const Timeout<std::micro> &timeout) {
return RunShellCommand(llvm::StringRef(), command, working_dir, status_ptr,
signo_ptr, command_output, timeout);
}
lldb_private::Status Platform::RunShellCommand(
llvm::StringRef shell, // Pass empty if you want to use the default
// shell interpreter
llvm::StringRef command, // Shouldn't be empty
const FileSpec &
working_dir, // Pass empty FileSpec to use the current working directory
int *status_ptr, // Pass nullptr if you don't want the process exit status
int *signo_ptr, // Pass nullptr if you don't want the signal that caused the
// process to exit
std::string
*command_output, // Pass nullptr if you don't want the command output
const Timeout<std::micro> &timeout) {
if (IsHost())
return Host::RunShellCommand(shell, command, working_dir, status_ptr,
signo_ptr, command_output, timeout);
return Status::FromErrorString(
"unable to run a remote command without a platform");
}
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
llvm::ErrorOr<llvm::MD5::MD5Result>
Platform::CalculateMD5(const FileSpec &file_spec) {
if (!IsHost())
[lldb] Unify CalculateMD5 return types (#91029) This is a retake of https://github.com/llvm/llvm-project/pull/90921 which got reverted because I forgot to modify the CalculateMD5 unit test I had added in https://github.com/llvm/llvm-project/pull/88812 The prior failing build is here: https://lab.llvm.org/buildbot/#/builders/68/builds/73622 To make sure this error doesn't happen, I ran `ninja ProcessGdbRemoteTests` and then executed the resulting test binary and observed the `CalculateMD5` test passed. # Overview In my previous PR: https://github.com/llvm/llvm-project/pull/88812, @JDevlieghere suggested to match return types of the various calculate md5 functions. This PR achieves that by changing the various calculate md5 functions to return `llvm::ErrorOr<llvm::MD5::MD5Result>`.   The suggestion was to go for `std::optional<>` but I opted for `llvm::ErrorOr<>` because local calculate md5 was already possibly returning `ErrorOr`. To make sure I didn't break the md5 calculation functionality, I ran some tests for the gdb remote client, and things seem to work. # Testing 1. Remote file doesn't exist ![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77) 1. Remote file differs ![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491) 1. Remote file matches ![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce) ## Test gaps Unfortunately, I had to modify `lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I can't test the changes there. Hopefully, the existing test suite / code review from whomever is reading this will catch any issues.
2024-05-09 15:57:46 -07:00
return std::make_error_code(std::errc::not_supported);
return llvm::sys::fs::md5_contents(file_spec.GetPath());
}
void Platform::SetLocalCacheDirectory(const char *local) {
m_local_cache_directory.assign(local);
}
const char *Platform::GetLocalCacheDirectory() {
return m_local_cache_directory.c_str();
}
static constexpr OptionDefinition g_rsync_option_table[] = {
{LLDB_OPT_SET_ALL, false, "rsync", 'r', OptionParser::eNoArgument, nullptr,
{}, 0, eArgTypeNone, "Enable rsync."},
{LLDB_OPT_SET_ALL, false, "rsync-opts", 'R',
OptionParser::eRequiredArgument, nullptr, {}, 0, eArgTypeCommandName,
"Platform-specific options required for rsync to work."},
{LLDB_OPT_SET_ALL, false, "rsync-prefix", 'P',
OptionParser::eRequiredArgument, nullptr, {}, 0, eArgTypeCommandName,
"Platform-specific rsync prefix put before the remote path."},
{LLDB_OPT_SET_ALL, false, "ignore-remote-hostname", 'i',
OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone,
"Do not automatically fill in the remote hostname when composing the "
"rsync command."},
};
static constexpr OptionDefinition g_ssh_option_table[] = {
{LLDB_OPT_SET_ALL, false, "ssh", 's', OptionParser::eNoArgument, nullptr,
{}, 0, eArgTypeNone, "Enable SSH."},
{LLDB_OPT_SET_ALL, false, "ssh-opts", 'S', OptionParser::eRequiredArgument,
nullptr, {}, 0, eArgTypeCommandName,
"Platform-specific options required for SSH to work."},
};
static constexpr OptionDefinition g_caching_option_table[] = {
{LLDB_OPT_SET_ALL, false, "local-cache-dir", 'c',
OptionParser::eRequiredArgument, nullptr, {}, 0, eArgTypePath,
"Path in which to store local copies of files."},
};
llvm::ArrayRef<OptionDefinition> OptionGroupPlatformRSync::GetDefinitions() {
return llvm::ArrayRef(g_rsync_option_table);
}
void OptionGroupPlatformRSync::OptionParsingStarting(
ExecutionContext *execution_context) {
m_rsync = false;
m_rsync_opts.clear();
m_rsync_prefix.clear();
m_ignores_remote_hostname = false;
}
lldb_private::Status
OptionGroupPlatformRSync::SetOptionValue(uint32_t option_idx,
llvm::StringRef option_arg,
ExecutionContext *execution_context) {
Status error;
char short_option = (char)GetDefinitions()[option_idx].short_option;
switch (short_option) {
case 'r':
m_rsync = true;
break;
case 'R':
m_rsync_opts.assign(std::string(option_arg));
break;
case 'P':
m_rsync_prefix.assign(std::string(option_arg));
break;
case 'i':
m_ignores_remote_hostname = true;
break;
default:
error = Status::FromErrorStringWithFormat("unrecognized option '%c'",
short_option);
break;
}
return error;
}
lldb::BreakpointSP
Platform::SetThreadCreationBreakpoint(lldb_private::Target &target) {
return lldb::BreakpointSP();
}
llvm::ArrayRef<OptionDefinition> OptionGroupPlatformSSH::GetDefinitions() {
return llvm::ArrayRef(g_ssh_option_table);
}
void OptionGroupPlatformSSH::OptionParsingStarting(
ExecutionContext *execution_context) {
m_ssh = false;
m_ssh_opts.clear();
}
lldb_private::Status
OptionGroupPlatformSSH::SetOptionValue(uint32_t option_idx,
llvm::StringRef option_arg,
ExecutionContext *execution_context) {
Status error;
char short_option = (char)GetDefinitions()[option_idx].short_option;
switch (short_option) {
case 's':
m_ssh = true;
break;
case 'S':
m_ssh_opts.assign(std::string(option_arg));
break;
default:
error = Status::FromErrorStringWithFormat("unrecognized option '%c'",
short_option);
break;
}
return error;
}
llvm::ArrayRef<OptionDefinition> OptionGroupPlatformCaching::GetDefinitions() {
return llvm::ArrayRef(g_caching_option_table);
}
void OptionGroupPlatformCaching::OptionParsingStarting(
ExecutionContext *execution_context) {
m_cache_dir.clear();
}
lldb_private::Status OptionGroupPlatformCaching::SetOptionValue(
uint32_t option_idx, llvm::StringRef option_arg,
ExecutionContext *execution_context) {
Status error;
char short_option = (char)GetDefinitions()[option_idx].short_option;
switch (short_option) {
case 'c':
m_cache_dir.assign(std::string(option_arg));
break;
default:
error = Status::FromErrorStringWithFormat("unrecognized option '%c'",
short_option);
break;
}
return error;
}
Environment Platform::GetEnvironment() {
if (IsHost())
return Host::GetEnvironment();
return Environment();
}
const std::vector<ConstString> &Platform::GetTrapHandlerSymbolNames() {
if (!m_calculated_trap_handlers) {
std::lock_guard<std::mutex> guard(m_mutex);
if (!m_calculated_trap_handlers) {
CalculateTrapHandlerSymbolNames();
m_calculated_trap_handlers = true;
}
}
return m_trap_handlers;
}
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
Status
Platform::GetCachedExecutable(ModuleSpec &module_spec,
lldb::ModuleSP &module_sp,
const FileSpecList *module_search_paths_ptr) {
FileSpec platform_spec = module_spec.GetFileSpec();
Status error = GetRemoteSharedModule(
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
module_spec, nullptr, module_sp,
[&](const ModuleSpec &spec) {
return Platform::ResolveExecutable(spec, module_sp,
module_search_paths_ptr);
[lldb] Refactor Platform::ResolveExecutable Module resolution is probably the most complex piece of lldb [citation needed], with numerous levels of abstraction, each one implementing various retry and fallback strategies. It is also a very repetitive, with only small differences between "host", "remote-and-connected" and "remote-but-not-(yet)-connected" scenarios. The goal of this patch (first in series) is to reduce the number of abstractions, and deduplicate the code. One of the reasons for this complexity is the tension between the desire to offload the process of module resolution to the remote platform instance (that's how most other platform methods work), and the desire to keep it local to the outer platform class (its easier to subclass the outer class, and it generally makes more sense). This patch resolves that conflict in favour of doing everything in the outer class. The gdb-remote (our only remote platform) implementation of ResolveExecutable was not doing anything gdb-specific, and was rather similar to the other implementations of that method (any divergence is most likely the result of fixes not being applied everywhere rather than intentional). It does this by excising the remote platform out of the resolution codepath. The gdb-remote implementation of ResolveExecutable is moved to Platform::ResolveRemoteExecutable, and the (only) call site is redirected to that. On its own, this does not achieve (much), but it creates new opportunities for layer peeling and code sharing, since all of the code now lives closer together. Differential Revision: https://reviews.llvm.org/D113487
2021-11-09 16:32:57 +01:00
},
nullptr);
if (error.Success()) {
module_spec.GetFileSpec() = module_sp->GetFileSpec();
module_spec.GetPlatformFileSpec() = platform_spec;
}
return error;
}
Status Platform::GetRemoteSharedModule(const ModuleSpec &module_spec,
Process *process,
lldb::ModuleSP &module_sp,
const ModuleResolver &module_resolver,
bool *did_create_ptr) {
// Get module information from a target.
ModuleSpec resolved_module_spec;
ArchSpec process_host_arch;
bool got_module_spec = false;
if (process) {
process_host_arch = process->GetSystemArchitecture();
// Try to get module information from the process
if (process->GetModuleSpec(module_spec.GetFileSpec(),
module_spec.GetArchitecture(),
resolved_module_spec)) {
if (!module_spec.GetUUID().IsValid() ||
module_spec.GetUUID() == resolved_module_spec.GetUUID()) {
got_module_spec = true;
}
}
}
if (!module_spec.GetArchitecture().IsValid()) {
Status error;
// No valid architecture was specified, ask the platform for the
// architectures that we should be using (in the correct order) and see if
// we can find a match that way
ModuleSpec arch_module_spec(module_spec);
for (const ArchSpec &arch : GetSupportedArchitectures(process_host_arch)) {
arch_module_spec.GetArchitecture() = arch;
error = ModuleList::GetSharedModule(arch_module_spec, module_sp, nullptr,
nullptr, nullptr);
// Did we find an executable using one of the
if (error.Success() && module_sp)
break;
}
if (module_sp) {
resolved_module_spec = arch_module_spec;
got_module_spec = true;
}
}
if (!got_module_spec) {
// Get module information from a target.
if (GetModuleSpec(module_spec.GetFileSpec(), module_spec.GetArchitecture(),
resolved_module_spec)) {
if (!module_spec.GetUUID().IsValid() ||
module_spec.GetUUID() == resolved_module_spec.GetUUID()) {
got_module_spec = true;
}
}
}
if (!got_module_spec) {
// Fall back to the given module resolver, which may have its own
// search logic.
return module_resolver(module_spec);
}
// If we are looking for a specific UUID, make sure resolved_module_spec has
// the same one before we search.
if (module_spec.GetUUID().IsValid()) {
resolved_module_spec.GetUUID() = module_spec.GetUUID();
}
// Call locate module callback if set. This allows users to implement their
// own module cache system. For example, to leverage build system artifacts,
// to bypass pulling files from remote platform, or to search symbol files
// from symbol servers.
FileSpec symbol_file_spec;
CallLocateModuleCallbackIfSet(resolved_module_spec, module_sp,
symbol_file_spec, did_create_ptr);
if (module_sp) {
// The module is loaded.
if (symbol_file_spec) {
// 1. module_sp:loaded, symbol_file_spec:set
// The callback found a module file and a symbol file for this
// resolved_module_spec. Set the symbol file to the module.
module_sp->SetSymbolFileFileSpec(symbol_file_spec);
} else {
// 2. module_sp:loaded, symbol_file_spec:empty
// The callback only found a module file for this
// resolved_module_spec.
}
return Status();
}
// The module is not loaded by CallLocateModuleCallbackIfSet.
// 3. module_sp:empty, symbol_file_spec:set
// The callback only found a symbol file for the module. We continue to
// find a module file for this resolved_module_spec. and we will call
// module_sp->SetSymbolFileFileSpec with the symbol_file_spec later.
// 4. module_sp:empty, symbol_file_spec:empty
// The callback is not set. Or the callback did not find any module
// files nor any symbol files. Or the callback failed, or something
// went wrong. We continue to find a module file for this
// resolved_module_spec.
// Trying to find a module by UUID on local file system.
Status error = module_resolver(resolved_module_spec);
if (error.Success()) {
if (module_sp && symbol_file_spec) {
// Set the symbol file to the module if the locate modudle callback was
// called and returned only a symbol file.
module_sp->SetSymbolFileFileSpec(symbol_file_spec);
}
return error;
}
// Fallback to call GetCachedSharedModule on failure.
if (GetCachedSharedModule(resolved_module_spec, module_sp, did_create_ptr)) {
if (module_sp && symbol_file_spec) {
// Set the symbol file to the module if the locate modudle callback was
// called and returned only a symbol file.
module_sp->SetSymbolFileFileSpec(symbol_file_spec);
}
return Status();
}
return Status::FromErrorStringWithFormat(
"Failed to call GetCachedSharedModule");
}
void Platform::CallLocateModuleCallbackIfSet(const ModuleSpec &module_spec,
lldb::ModuleSP &module_sp,
FileSpec &symbol_file_spec,
bool *did_create_ptr) {
if (!m_locate_module_callback) {
// Locate module callback is not set.
return;
}
FileSpec module_file_spec;
Status error =
m_locate_module_callback(module_spec, module_file_spec, symbol_file_spec);
// Locate module callback is set and called. Check the error.
Log *log = GetLog(LLDBLog::Platform);
if (error.Fail()) {
LLDB_LOGF(log, "%s: locate module callback failed: %s",
LLVM_PRETTY_FUNCTION, error.AsCString());
return;
}
// The locate module callback was succeeded.
// Check the module_file_spec and symbol_file_spec values.
// 1. module:empty symbol:empty -> Failure
// - The callback did not return any files.
// 2. module:exists symbol:exists -> Success
// - The callback returned a module file and a symbol file.
// 3. module:exists symbol:empty -> Success
// - The callback returned only a module file.
// 4. module:empty symbol:exists -> Success
// - The callback returned only a symbol file.
// For example, a breakpad symbol text file.
if (!module_file_spec && !symbol_file_spec) {
// This is '1. module:empty symbol:empty -> Failure'
// The callback did not return any files.
LLDB_LOGF(log,
"%s: locate module callback did not set both "
"module_file_spec and symbol_file_spec",
LLVM_PRETTY_FUNCTION);
return;
}
// If the callback returned a module file, it should exist.
if (module_file_spec && !FileSystem::Instance().Exists(module_file_spec)) {
LLDB_LOGF(log,
"%s: locate module callback set a non-existent file to "
"module_file_spec: %s",
LLVM_PRETTY_FUNCTION, module_file_spec.GetPath().c_str());
// Clear symbol_file_spec for the error.
symbol_file_spec.Clear();
return;
}
// If the callback returned a symbol file, it should exist.
if (symbol_file_spec && !FileSystem::Instance().Exists(symbol_file_spec)) {
LLDB_LOGF(log,
"%s: locate module callback set a non-existent file to "
"symbol_file_spec: %s",
LLVM_PRETTY_FUNCTION, symbol_file_spec.GetPath().c_str());
// Clear symbol_file_spec for the error.
symbol_file_spec.Clear();
return;
}
if (!module_file_spec && symbol_file_spec) {
// This is '4. module:empty symbol:exists -> Success'
// The locate module callback returned only a symbol file. For example,
// a breakpad symbol text file. GetRemoteSharedModule will use this returned
// symbol_file_spec.
LLDB_LOGF(log, "%s: locate module callback succeeded: symbol=%s",
LLVM_PRETTY_FUNCTION, symbol_file_spec.GetPath().c_str());
return;
}
// This is one of the following.
// - 2. module:exists symbol:exists -> Success
// - The callback returned a module file and a symbol file.
// - 3. module:exists symbol:empty -> Success
// - The callback returned Only a module file.
// Load the module file.
auto cached_module_spec(module_spec);
cached_module_spec.GetUUID().Clear(); // Clear UUID since it may contain md5
// content hash instead of real UUID.
cached_module_spec.GetFileSpec() = module_file_spec;
cached_module_spec.GetPlatformFileSpec() = module_spec.GetFileSpec();
cached_module_spec.SetObjectOffset(0);
error = ModuleList::GetSharedModule(cached_module_spec, module_sp, nullptr,
nullptr, did_create_ptr, false);
if (error.Success() && module_sp) {
// Succeeded to load the module file.
LLDB_LOGF(log, "%s: locate module callback succeeded: module=%s symbol=%s",
LLVM_PRETTY_FUNCTION, module_file_spec.GetPath().c_str(),
symbol_file_spec.GetPath().c_str());
} else {
LLDB_LOGF(log,
"%s: locate module callback succeeded but failed to load: "
"module=%s symbol=%s",
LLVM_PRETTY_FUNCTION, module_file_spec.GetPath().c_str(),
symbol_file_spec.GetPath().c_str());
// Clear module_sp and symbol_file_spec for the error.
module_sp.reset();
symbol_file_spec.Clear();
}
}
bool Platform::GetCachedSharedModule(const ModuleSpec &module_spec,
lldb::ModuleSP &module_sp,
bool *did_create_ptr) {
if (IsHost() || !GetGlobalPlatformProperties().GetUseModuleCache() ||
!GetGlobalPlatformProperties().GetModuleCacheDirectory())
return false;
Log *log = GetLog(LLDBLog::Platform);
// Check local cache for a module.
auto error = m_module_cache->GetAndPut(
GetModuleCacheRoot(), GetCacheHostname(), module_spec,
[this](const ModuleSpec &module_spec,
const FileSpec &tmp_download_file_spec) {
return DownloadModuleSlice(
module_spec.GetFileSpec(), module_spec.GetObjectOffset(),
module_spec.GetObjectSize(), tmp_download_file_spec);
},
[this](const ModuleSP &module_sp,
const FileSpec &tmp_download_file_spec) {
return DownloadSymbolFile(module_sp, tmp_download_file_spec);
},
module_sp, did_create_ptr);
if (error.Success())
return true;
LLDB_LOGF(log, "Platform::%s - module %s not found in local cache: %s",
__FUNCTION__, module_spec.GetUUID().GetAsString().c_str(),
error.AsCString());
return false;
}
Status Platform::DownloadModuleSlice(const FileSpec &src_file_spec,
const uint64_t src_offset,
const uint64_t src_size,
const FileSpec &dst_file_spec) {
Status error;
std::error_code EC;
llvm::raw_fd_ostream dst(dst_file_spec.GetPath(), EC, llvm::sys::fs::OF_None);
if (EC) {
error = Status::FromErrorStringWithFormat(
"unable to open destination file: %s", dst_file_spec.GetPath().c_str());
return error;
}
auto src_fd = OpenFile(src_file_spec, File::eOpenOptionReadOnly,
lldb::eFilePermissionsFileDefault, error);
if (error.Fail()) {
error = Status::FromErrorStringWithFormat("unable to open source file: %s",
error.AsCString());
return error;
}
lldb: do more than 1 kilobyte at a time to vastly increase binary sync speed https://github.com/llvm/llvm-project/issues/62750 I setup a simple test with a large .so (~100MiB) that was only present on the target machine but not present on the local machine, and ran a lldb server on the target and connectd to it. LLDB properly downloads the file from the remote, but it does so at a very slow speed, even over a hardwired 1Gbps connection! Increasing the buffer size for downloading these helps quite a bit. Test setup: ``` $ cat gen.py print('const char* hugeglobal = ') for _ in range(1000*500): print(' "' + '1234'*50 + '"') print(';') print('const char* mystring() { return hugeglobal; }') $ gen.py > huge.c $ mkdir libdir $ gcc -fPIC huge.c -Wl,-soname,libhuge.so -o libdir/libhuge.so -shared $ cat test.c #include <string.h> #include <stdio.h> extern const char* mystring(); int main() { printf("%d\n", strlen(mystring())); } $ gcc test.c -L libdir -l huge -Wl,-rpath='$ORIGIN' -o test $ rsync -a libdir remote:~/ $ ssh remote bash -c "cd ~/libdir && /llvm/buildr/bin/lldb-server platform --server --listen '*:1234'" ``` in another terminal ``` $ rm -rf ~/.lldb # clear cache $ cat connect.lldb platform select remote-linux platform connect connect://10.0.0.14:1234 file test b main r image list c q $ time /llvm/buildr/bin/lldb --source connect.lldb ``` Times with various buffer sizes: 1kiB (current): ~22s 8kiB: ~8s 16kiB: ~4s 32kiB: ~3.5s 64kiB: ~2.8s 128kiB: ~2.6s 256kiB: ~2.1s 512kiB: ~2.1s 1MiB: ~2.1s 2MiB: ~2.1s I choose 512kiB from this list as it seems to be the place where the returns start diminishing and still isn't that much memory My understanding of how this makes such a difference is ReadFile issues a request for each call, and larger buffer means less round trip times. The "ideal" situation is ReadFile() being async and being able to issue multiple of these, but that is much more work for probably little gains. NOTE: this is my first contribution, so wasn't sure who to choose as a reviewer. Greg Clayton seems to be the most appropriate of those in CODE_OWNERS.txt Reviewed By: clayborg, jasonmolenda Differential Revision: https://reviews.llvm.org/D153060
2023-06-19 09:59:20 +00:00
std::vector<char> buffer(512 * 1024);
auto offset = src_offset;
uint64_t total_bytes_read = 0;
while (total_bytes_read < src_size) {
const auto to_read = std::min(static_cast<uint64_t>(buffer.size()),
src_size - total_bytes_read);
const uint64_t n_read =
ReadFile(src_fd, offset, &buffer[0], to_read, error);
if (error.Fail())
break;
if (n_read == 0) {
error = Status::FromErrorString("read 0 bytes");
break;
}
offset += n_read;
total_bytes_read += n_read;
dst.write(&buffer[0], n_read);
}
Status close_error;
CloseFile(src_fd, close_error); // Ignoring close error.
return error;
}
Status Platform::DownloadSymbolFile(const lldb::ModuleSP &module_sp,
const FileSpec &dst_file_spec) {
return Status::FromErrorString(
"Symbol file downloading not supported by the default platform.");
}
FileSpec Platform::GetModuleCacheRoot() {
auto dir_spec = GetGlobalPlatformProperties().GetModuleCacheDirectory();
dir_spec.AppendPathComponent(GetPluginName());
return dir_spec;
}
const char *Platform::GetCacheHostname() { return GetHostname(); }
const UnixSignalsSP &Platform::GetRemoteUnixSignals() {
static const auto s_default_unix_signals_sp = std::make_shared<UnixSignals>();
return s_default_unix_signals_sp;
}
UnixSignalsSP Platform::GetUnixSignals() {
if (IsHost())
return UnixSignals::CreateForHost();
return GetRemoteUnixSignals();
}
uint32_t Platform::LoadImage(lldb_private::Process *process,
const lldb_private::FileSpec &local_file,
const lldb_private::FileSpec &remote_file,
lldb_private::Status &error) {
if (local_file && remote_file) {
// Both local and remote file was specified. Install the local file to the
// given location.
if (IsRemote() || local_file != remote_file) {
error = Install(local_file, remote_file);
if (error.Fail())
return LLDB_INVALID_IMAGE_TOKEN;
}
return DoLoadImage(process, remote_file, nullptr, error);
}
if (local_file) {
// Only local file was specified. Install it to the current working
// directory.
FileSpec target_file = GetWorkingDirectory();
target_file.AppendPathComponent(local_file.GetFilename().AsCString());
if (IsRemote() || local_file != target_file) {
error = Install(local_file, target_file);
if (error.Fail())
return LLDB_INVALID_IMAGE_TOKEN;
}
return DoLoadImage(process, target_file, nullptr, error);
}
if (remote_file) {
// Only remote file was specified so we don't have to do any copying
return DoLoadImage(process, remote_file, nullptr, error);
}
error =
Status::FromErrorString("Neither local nor remote file was specified");
return LLDB_INVALID_IMAGE_TOKEN;
}
uint32_t Platform::DoLoadImage(lldb_private::Process *process,
const lldb_private::FileSpec &remote_file,
const std::vector<std::string> *paths,
lldb_private::Status &error,
lldb_private::FileSpec *loaded_image) {
error = Status::FromErrorString(
"LoadImage is not supported on the current platform");
return LLDB_INVALID_IMAGE_TOKEN;
}
uint32_t Platform::LoadImageUsingPaths(lldb_private::Process *process,
const lldb_private::FileSpec &remote_filename,
const std::vector<std::string> &paths,
lldb_private::Status &error,
lldb_private::FileSpec *loaded_path)
{
FileSpec file_to_use;
if (remote_filename.IsAbsolute())
file_to_use = FileSpec(remote_filename.GetFilename().GetStringRef(),
remote_filename.GetPathStyle());
else
file_to_use = remote_filename;
return DoLoadImage(process, file_to_use, &paths, error, loaded_path);
}
Status Platform::UnloadImage(lldb_private::Process *process,
uint32_t image_token) {
return Status::FromErrorString(
"UnloadImage is not supported on the current platform");
}
lldb::ProcessSP Platform::ConnectProcess(llvm::StringRef connect_url,
llvm::StringRef plugin_name,
Debugger &debugger, Target *target,
Status &error) {
return DoConnectProcess(connect_url, plugin_name, debugger, nullptr, target,
error);
}
lldb::ProcessSP Platform::ConnectProcessSynchronous(
llvm::StringRef connect_url, llvm::StringRef plugin_name,
Debugger &debugger, Stream &stream, Target *target, Status &error) {
return DoConnectProcess(connect_url, plugin_name, debugger, &stream, target,
error);
}
lldb::ProcessSP Platform::DoConnectProcess(llvm::StringRef connect_url,
llvm::StringRef plugin_name,
Debugger &debugger, Stream *stream,
Target *target, Status &error) {
error.Clear();
if (!target) {
ArchSpec arch = Target::GetDefaultArchitecture();
const char *triple =
arch.IsValid() ? arch.GetTriple().getTriple().c_str() : "";
TargetSP new_target_sp;
error = debugger.GetTargetList().CreateTarget(
debugger, "", triple, eLoadDependentsNo, nullptr, new_target_sp);
target = new_target_sp.get();
if (!target || error.Fail()) {
return nullptr;
}
}
lldb::ProcessSP process_sp =
target->CreateProcess(debugger.GetListener(), plugin_name, nullptr, true);
if (!process_sp)
return nullptr;
// If this private method is called with a stream we are synchronous.
const bool synchronous = stream != nullptr;
ListenerSP listener_sp(
Listener::MakeListener("lldb.Process.ConnectProcess.hijack"));
if (synchronous)
process_sp->HijackProcessEvents(listener_sp);
error = process_sp->ConnectRemote(connect_url);
if (error.Fail()) {
if (synchronous)
process_sp->RestoreProcessEvents();
return nullptr;
}
if (synchronous) {
EventSP event_sp;
process_sp->WaitForProcessToStop(std::nullopt, &event_sp, true, listener_sp,
nullptr);
process_sp->RestoreProcessEvents();
bool pop_process_io_handler = false;
// This is a user-level stop, so we allow recognizers to select frames.
Process::HandleProcessStateChangedEvent(
event_sp, stream, SelectMostRelevantFrame, pop_process_io_handler);
}
return process_sp;
}
size_t Platform::ConnectToWaitingProcesses(lldb_private::Debugger &debugger,
lldb_private::Status &error) {
error.Clear();
return 0;
}
size_t Platform::GetSoftwareBreakpointTrapOpcode(Target &target,
BreakpointSite *bp_site) {
ArchSpec arch = target.GetArchitecture();
assert(arch.IsValid());
const uint8_t *trap_opcode = nullptr;
size_t trap_opcode_size = 0;
switch (arch.GetMachine()) {
case llvm::Triple::aarch64_32:
case llvm::Triple::aarch64: {
static const uint8_t g_aarch64_opcode[] = {0x00, 0x00, 0x20, 0xd4};
trap_opcode = g_aarch64_opcode;
trap_opcode_size = sizeof(g_aarch64_opcode);
Support Linux on SystemZ as platform This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-04-14 14:28:34 +00:00
} break;
case llvm::Triple::arc: {
static const uint8_t g_hex_opcode[] = { 0xff, 0x7f };
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
// TODO: support big-endian arm and thumb trap codes.
Support Linux on SystemZ as platform This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-04-14 14:28:34 +00:00
case llvm::Triple::arm: {
// The ARM reference recommends the use of 0xe7fddefe and 0xdefe but the
// linux kernel does otherwise.
Support Linux on SystemZ as platform This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-04-14 14:28:34 +00:00
static const uint8_t g_arm_breakpoint_opcode[] = {0xf0, 0x01, 0xf0, 0xe7};
static const uint8_t g_thumb_breakpoint_opcode[] = {0x01, 0xde};
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845) This patch is rearranging code a bit to add WatchpointResources to Process. A WatchpointResource is meant to represent a hardware watchpoint register in the inferior process. It has an address, a size, a type, and a list of Watchpoints that are using this WatchpointResource. This current patch doesn't add any of the features of WatchpointResources that make them interesting -- a user asking to watch a 24 byte object could watch this with three 8 byte WatchpointResources. Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint registers were used to track these separately, one of them may not be hit. Or if you have one Watchpoint on a variable with a condition set, and another Watchpoint on that same variable with a command defined or different condition, or ignorecount, both of those Watchpoints need to evaluate their criteria/commands when their WatchpointResource has been hit. There's a bit of code movement to rearrange things in the direction I'll need for implementing this feature, so I want to start with reviewing & landing this mostly NFC patch and we can focus on the algorithmic choices about how WatchpointResources are shared and handled as they're triggeed, separately. This patch also stops printing "Watchpoint <n> hit: old value: <x>, new vlaue: <y>" for Read watchpoints. I could make an argument for print "Watchpoint <n> hit: current value <x>" but the current output doesn't make any sense, and the user can print the value if they are particularly interested. Read watchpoints are used primarily to understand what code is reading a variable. This patch adds more fallbacks for how to print the objects being watched if we have types, instead of assuming they are all integral values, so a struct will print its elements. As large watchpoints are added, we'll be doing a lot more of those. To track the WatchpointSP in the WatchpointResources, I changed the internal API which took a WatchpointSP and devolved it to a Watchpoint*, which meant touching several different Process files. I removed the watchpoint code in ProcessKDP which only reported that watchpoints aren't supported, the base class does that already. I haven't yet changed how we receive a watchpoint to identify the WatchpointResource responsible for the trigger, and identify all Watchpoints that are using this Resource to evaluate their conditions etc. This is the same work that a BreakpointSite needs to do when it has been tiggered, where multiple Breakpoints may be at the same address. There is not yet any printing of the Resources that a Watchpoint is implemented in terms of ("watchpoint list", or SBWatchpoint::GetDescription). "watchpoint set var" and "watchpoint set expression" take a size argument which was previously 1, 2, 4, or 8 (an enum). I've changed this to an unsigned int. Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with Resources we'll allow a user to ask for different sized watchpoints and set them in hardware-expressble terms soon. I've annotated areas where I know there is work still needed with LWP_TODO that I'll be working on once this is landed. I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS. https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 (cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
lldb::BreakpointLocationSP bp_loc_sp(bp_site->GetConstituentAtIndex(0));
AddressClass addr_class = AddressClass::eUnknown;
if (bp_loc_sp) {
addr_class = bp_loc_sp->GetAddress().GetAddressClass();
if (addr_class == AddressClass::eUnknown &&
(bp_loc_sp->GetAddress().GetFileAddress() & 1))
addr_class = AddressClass::eCodeAlternateISA;
}
if (addr_class == AddressClass::eCodeAlternateISA) {
trap_opcode = g_thumb_breakpoint_opcode;
trap_opcode_size = sizeof(g_thumb_breakpoint_opcode);
} else {
trap_opcode = g_arm_breakpoint_opcode;
trap_opcode_size = sizeof(g_arm_breakpoint_opcode);
}
} break;
case llvm::Triple::avr: {
static const uint8_t g_hex_opcode[] = {0x98, 0x95};
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
case llvm::Triple::mips:
case llvm::Triple::mips64: {
static const uint8_t g_hex_opcode[] = {0x00, 0x00, 0x00, 0x0d};
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
case llvm::Triple::mipsel:
case llvm::Triple::mips64el: {
static const uint8_t g_hex_opcode[] = {0x0d, 0x00, 0x00, 0x00};
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
case llvm::Triple::msp430: {
static const uint8_t g_msp430_opcode[] = {0x43, 0x43};
trap_opcode = g_msp430_opcode;
trap_opcode_size = sizeof(g_msp430_opcode);
} break;
case llvm::Triple::systemz: {
static const uint8_t g_hex_opcode[] = {0x00, 0x01};
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
case llvm::Triple::hexagon: {
static const uint8_t g_hex_opcode[] = {0x0c, 0xdb, 0x00, 0x54};
trap_opcode = g_hex_opcode;
trap_opcode_size = sizeof(g_hex_opcode);
} break;
case llvm::Triple::ppc:
case llvm::Triple::ppc64: {
static const uint8_t g_ppc_opcode[] = {0x7f, 0xe0, 0x00, 0x08};
trap_opcode = g_ppc_opcode;
trap_opcode_size = sizeof(g_ppc_opcode);
} break;
case llvm::Triple::ppc64le: {
static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
trap_opcode = g_ppc64le_opcode;
trap_opcode_size = sizeof(g_ppc64le_opcode);
} break;
case llvm::Triple::x86:
case llvm::Triple::x86_64: {
static const uint8_t g_i386_opcode[] = {0xCC};
trap_opcode = g_i386_opcode;
trap_opcode_size = sizeof(g_i386_opcode);
} break;
case llvm::Triple::riscv32:
case llvm::Triple::riscv64: {
static const uint8_t g_riscv_opcode[] = {0x73, 0x00, 0x10, 0x00}; // ebreak
static const uint8_t g_riscv_opcode_c[] = {0x02, 0x90}; // c.ebreak
if (arch.GetFlags() & ArchSpec::eRISCV_rvc) {
trap_opcode = g_riscv_opcode_c;
trap_opcode_size = sizeof(g_riscv_opcode_c);
} else {
trap_opcode = g_riscv_opcode;
trap_opcode_size = sizeof(g_riscv_opcode);
}
} break;
case llvm::Triple::loongarch32:
case llvm::Triple::loongarch64: {
static const uint8_t g_loongarch_opcode[] = {0x05, 0x00, 0x2a,
0x00}; // break 0x5
trap_opcode = g_loongarch_opcode;
trap_opcode_size = sizeof(g_loongarch_opcode);
} break;
default:
return 0;
}
assert(bp_site);
if (bp_site->SetTrapOpcode(trap_opcode, trap_opcode_size))
return trap_opcode_size;
return 0;
}
CompilerType Platform::GetSiginfoType(const llvm::Triple& triple) {
return CompilerType();
}
Args Platform::GetExtraStartupCommands() {
return {};
}
void Platform::SetLocateModuleCallback(LocateModuleCallback callback) {
m_locate_module_callback = callback;
}
Platform::LocateModuleCallback Platform::GetLocateModuleCallback() const {
return m_locate_module_callback;
}
PlatformSP PlatformList::GetOrCreate(llvm::StringRef name) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
for (const PlatformSP &platform_sp : m_platforms) {
if (platform_sp->GetName() == name)
return platform_sp;
}
return Create(name);
}
PlatformSP PlatformList::GetOrCreate(const ArchSpec &arch,
const ArchSpec &process_host_arch,
ArchSpec *platform_arch_ptr,
Status &error) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
// First try exact arch matches across all platforms already created
for (const auto &platform_sp : m_platforms) {
if (platform_sp->IsCompatibleArchitecture(
arch, process_host_arch, ArchSpec::ExactMatch, platform_arch_ptr))
return platform_sp;
}
// Next try compatible arch matches across all platforms already created
for (const auto &platform_sp : m_platforms) {
if (platform_sp->IsCompatibleArchitecture(arch, process_host_arch,
ArchSpec::CompatibleMatch,
platform_arch_ptr))
return platform_sp;
}
PlatformCreateInstance create_callback;
// First try exact arch matches across all platform plug-ins
uint32_t idx;
for (idx = 0;
(create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
++idx) {
PlatformSP platform_sp = create_callback(false, &arch);
if (platform_sp &&
platform_sp->IsCompatibleArchitecture(
arch, process_host_arch, ArchSpec::ExactMatch, platform_arch_ptr)) {
m_platforms.push_back(platform_sp);
return platform_sp;
}
}
// Next try compatible arch matches across all platform plug-ins
for (idx = 0;
(create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
++idx) {
PlatformSP platform_sp = create_callback(false, &arch);
if (platform_sp && platform_sp->IsCompatibleArchitecture(
arch, process_host_arch, ArchSpec::CompatibleMatch,
platform_arch_ptr)) {
m_platforms.push_back(platform_sp);
return platform_sp;
}
}
if (platform_arch_ptr)
platform_arch_ptr->Clear();
return nullptr;
}
PlatformSP PlatformList::GetOrCreate(const ArchSpec &arch,
const ArchSpec &process_host_arch,
ArchSpec *platform_arch_ptr) {
Status error;
if (arch.IsValid())
return GetOrCreate(arch, process_host_arch, platform_arch_ptr, error);
return nullptr;
}
PlatformSP PlatformList::GetOrCreate(llvm::ArrayRef<ArchSpec> archs,
const ArchSpec &process_host_arch,
std::vector<PlatformSP> &candidates) {
candidates.clear();
candidates.reserve(archs.size());
if (archs.empty())
return nullptr;
PlatformSP host_platform_sp = Platform::GetHostPlatform();
// Prefer the selected platform if it matches at least one architecture.
if (m_selected_platform_sp) {
for (const ArchSpec &arch : archs) {
if (m_selected_platform_sp->IsCompatibleArchitecture(
arch, process_host_arch, ArchSpec::CompatibleMatch, nullptr))
return m_selected_platform_sp;
}
}
// Prefer the host platform if it matches at least one architecture.
if (host_platform_sp) {
for (const ArchSpec &arch : archs) {
if (host_platform_sp->IsCompatibleArchitecture(
arch, process_host_arch, ArchSpec::CompatibleMatch, nullptr))
return host_platform_sp;
}
}
// Collect a list of candidate platforms for the architectures.
for (const ArchSpec &arch : archs) {
if (PlatformSP platform = GetOrCreate(arch, process_host_arch, nullptr))
candidates.push_back(platform);
}
// The selected or host platform didn't match any of the architectures. If
// the same platform supports all architectures then that's the obvious next
// best thing.
if (candidates.size() == archs.size()) {
2022-08-14 16:25:36 -07:00
if (llvm::all_of(candidates, [&](const PlatformSP &p) -> bool {
return p->GetName() == candidates.front()->GetName();
})) {
return candidates.front();
}
}
// At this point we either have no platforms that match the given
// architectures or multiple platforms with no good way to disambiguate
// between them.
return nullptr;
}
PlatformSP PlatformList::Create(llvm::StringRef name) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
PlatformSP platform_sp = Platform::Create(name);
m_platforms.push_back(platform_sp);
return platform_sp;
}
bool PlatformList::LoadPlatformBinaryAndSetup(Process *process,
lldb::addr_t addr, bool notify) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
PlatformCreateInstance create_callback;
for (int idx = 0;
(create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
++idx) {
ArchSpec arch;
PlatformSP platform_sp = create_callback(true, &arch);
if (platform_sp) {
if (platform_sp->LoadPlatformBinaryAndSetup(process, addr, notify))
return true;
}
}
return false;
}