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

6093 lines
220 KiB
C++
Raw Normal View History

//===-- Process.cpp ---------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/lldb-python.h"
#include "lldb/Target/Process.h"
#include "lldb/lldb-private-log.h"
#include "lldb/Breakpoint/StoppointCallbackContext.h"
#include "lldb/Breakpoint/BreakpointLocation.h"
#include "lldb/Core/Event.h"
#include "lldb/Core/ConnectionFileDescriptor.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Log.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Symbol/Symbol.h"
#include "lldb/Core/PluginManager.h"
#include "lldb/Core/State.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Expression/ClangUserExpression.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Host/Host.h"
#include "lldb/Host/Terminal.h"
#include "lldb/Target/ABI.h"
#include "lldb/Target/DynamicLoader.h"
#include "lldb/Target/JITLoader.h"
#include "lldb/Target/OperatingSystem.h"
#include "lldb/Target/LanguageRuntime.h"
#include "lldb/Target/CPPLanguageRuntime.h"
#include "lldb/Target/ObjCLanguageRuntime.h"
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
#include "lldb/Target/Platform.h"
#include "lldb/Target/RegisterContext.h"
Abtracted the old "lldb_private::Thread::StopInfo" into an abtract class. This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo" that can completely describe any stop reason. It also provides a framework for doing intelligent things with the stop info at important times in the lifetime of the inferior. Examples include the signal stop info in StopInfoUnixSignal. It will check with the process to see that the current action is for the signal. These actions include wether to stop for the signal, wether the notify that the signal was hit, and wether to pass the signal along to the inferior process. The StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and this allows the stop info to determine if it should stop at the signal or continue the process. StopInfo subclasses must override the following functions: virtual lldb::StopReason GetStopReason () const = 0; virtual const char * GetDescription () = 0; StopInfo subclasses can override the following functions: // If the subclass returns "false", the inferior will resume. The default // version of this function returns "true" which means the default stop // info will stop the process. The breakpoint subclass will check if // the breakpoint wants us to stop by calling any installed callback on // the breakpoint, and also checking if the breakpoint is for the current // thread. Signals will check if they should stop based off of the // UnixSignal settings in the process. virtual bool ShouldStop (Event *event_ptr); // Sublasses can state if they want to notify the debugger when "ShouldStop" // returns false. This would be handy for breakpoints where you want to // log information and continue and is also used by the signal stop info // to notify that a signal was received (after it checks with the process // signal settings). virtual bool ShouldNotify (Event *event_ptr) { return false; } // Allow subclasses to do something intelligent right before we resume. // The signal class will figure out if the signal should be propagated // to the inferior process and pass that along to the debugger plug-ins. virtual void WillResume (lldb::StateType resume_state) { // By default, don't do anything } The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility folder and now doesn't polute the lldb_private::Thread class with platform specific code. llvm-svn: 110184
2010-08-04 09:40:35 +08:00
#include "lldb/Target/StopInfo.h"
#include "lldb/Target/SystemRuntime.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/TargetList.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Target/ThreadPlanBase.h"
#include "Plugins/Process/Utility/InferiorCallPOSIX.h"
#ifndef LLDB_DISABLE_POSIX
#include <spawn.h>
#endif
using namespace lldb;
using namespace lldb_private;
// Comment out line below to disable memory caching, overriding the process setting
// target.process.disable-memory-cache
#define ENABLE_MEMORY_CACHING
#ifdef ENABLE_MEMORY_CACHING
#define DISABLE_MEM_CACHE_DEFAULT false
#else
#define DISABLE_MEM_CACHE_DEFAULT true
#endif
class ProcessOptionValueProperties : public OptionValueProperties
{
public:
ProcessOptionValueProperties (const ConstString &name) :
OptionValueProperties (name)
{
}
// This constructor is used when creating ProcessOptionValueProperties when it
// is part of a new lldb_private::Process instance. It will copy all current
// global property values as needed
ProcessOptionValueProperties (ProcessProperties *global_properties) :
OptionValueProperties(*global_properties->GetValueProperties())
{
}
virtual const Property *
GetPropertyAtIndex (const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const
{
// When gettings the value for a key from the process options, we will always
// try and grab the setting from the current process if there is one. Else we just
// use the one from this instance.
if (exe_ctx)
{
Process *process = exe_ctx->GetProcessPtr();
if (process)
{
ProcessOptionValueProperties *instance_properties = static_cast<ProcessOptionValueProperties *>(process->GetValueProperties().get());
if (this != instance_properties)
return instance_properties->ProtectedGetPropertyAtIndex (idx);
}
}
return ProtectedGetPropertyAtIndex (idx);
}
};
static PropertyDefinition
g_properties[] =
{
{ "disable-memory-cache" , OptionValue::eTypeBoolean, false, DISABLE_MEM_CACHE_DEFAULT, NULL, NULL, "Disable reading and caching of memory in fixed-size units." },
{ "extra-startup-command", OptionValue::eTypeArray , false, OptionValue::eTypeString, NULL, NULL, "A list containing extra commands understood by the particular process plugin used. "
"For instance, to turn on debugserver logging set this to \"QSetLogging:bitmask=LOG_DEFAULT;\"" },
{ "ignore-breakpoints-in-expressions", OptionValue::eTypeBoolean, true, true, NULL, NULL, "If true, breakpoints will be ignored during expression evaluation." },
{ "unwind-on-error-in-expressions", OptionValue::eTypeBoolean, true, true, NULL, NULL, "If true, errors in expression evaluation will unwind the stack back to the state before the call." },
{ "python-os-plugin-path", OptionValue::eTypeFileSpec, false, true, NULL, NULL, "A path to a python OS plug-in module file that contains a OperatingSystemPlugIn class." },
{ "stop-on-sharedlibrary-events" , OptionValue::eTypeBoolean, true, false, NULL, NULL, "If true, stop when a shared library is loaded or unloaded." },
{ "detach-keeps-stopped" , OptionValue::eTypeBoolean, true, false, NULL, NULL, "If true, detach will attempt to keep the process stopped." },
{ NULL , OptionValue::eTypeInvalid, false, 0, NULL, NULL, NULL }
};
enum {
ePropertyDisableMemCache,
ePropertyExtraStartCommand,
ePropertyIgnoreBreakpointsInExpressions,
ePropertyUnwindOnErrorInExpressions,
ePropertyPythonOSPluginPath,
ePropertyStopOnSharedLibraryEvents,
ePropertyDetachKeepsStopped
};
ProcessProperties::ProcessProperties (bool is_global) :
Properties ()
{
if (is_global)
{
m_collection_sp.reset (new ProcessOptionValueProperties(ConstString("process")));
m_collection_sp->Initialize(g_properties);
m_collection_sp->AppendProperty(ConstString("thread"),
ConstString("Settings specific to threads."),
true,
Thread::GetGlobalProperties()->GetValueProperties());
}
else
m_collection_sp.reset (new ProcessOptionValueProperties(Process::GetGlobalProperties().get()));
}
ProcessProperties::~ProcessProperties()
{
}
bool
ProcessProperties::GetDisableMemoryCache() const
{
const uint32_t idx = ePropertyDisableMemCache;
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
}
Args
ProcessProperties::GetExtraStartupCommands () const
{
Args args;
const uint32_t idx = ePropertyExtraStartCommand;
m_collection_sp->GetPropertyAtIndexAsArgs(NULL, idx, args);
return args;
}
void
ProcessProperties::SetExtraStartupCommands (const Args &args)
{
const uint32_t idx = ePropertyExtraStartCommand;
m_collection_sp->SetPropertyAtIndexFromArgs(NULL, idx, args);
}
FileSpec
ProcessProperties::GetPythonOSPluginPath () const
{
const uint32_t idx = ePropertyPythonOSPluginPath;
return m_collection_sp->GetPropertyAtIndexAsFileSpec(NULL, idx);
}
void
ProcessProperties::SetPythonOSPluginPath (const FileSpec &file)
{
const uint32_t idx = ePropertyPythonOSPluginPath;
m_collection_sp->SetPropertyAtIndexAsFileSpec(NULL, idx, file);
}
bool
ProcessProperties::GetIgnoreBreakpointsInExpressions () const
{
const uint32_t idx = ePropertyIgnoreBreakpointsInExpressions;
return m_collection_sp->GetPropertyAtIndexAsBoolean(NULL, idx, g_properties[idx].default_uint_value != 0);
}
void
ProcessProperties::SetIgnoreBreakpointsInExpressions (bool ignore)
{
const uint32_t idx = ePropertyIgnoreBreakpointsInExpressions;
m_collection_sp->SetPropertyAtIndexAsBoolean(NULL, idx, ignore);
}
bool
ProcessProperties::GetUnwindOnErrorInExpressions () const
{
const uint32_t idx = ePropertyUnwindOnErrorInExpressions;
return m_collection_sp->GetPropertyAtIndexAsBoolean(NULL, idx, g_properties[idx].default_uint_value != 0);
}
void
ProcessProperties::SetUnwindOnErrorInExpressions (bool ignore)
{
const uint32_t idx = ePropertyUnwindOnErrorInExpressions;
m_collection_sp->SetPropertyAtIndexAsBoolean(NULL, idx, ignore);
}
bool
ProcessProperties::GetStopOnSharedLibraryEvents () const
{
const uint32_t idx = ePropertyStopOnSharedLibraryEvents;
return m_collection_sp->GetPropertyAtIndexAsBoolean(NULL, idx, g_properties[idx].default_uint_value != 0);
}
void
ProcessProperties::SetStopOnSharedLibraryEvents (bool stop)
{
const uint32_t idx = ePropertyStopOnSharedLibraryEvents;
m_collection_sp->SetPropertyAtIndexAsBoolean(NULL, idx, stop);
}
bool
ProcessProperties::GetDetachKeepsStopped () const
{
const uint32_t idx = ePropertyDetachKeepsStopped;
return m_collection_sp->GetPropertyAtIndexAsBoolean(NULL, idx, g_properties[idx].default_uint_value != 0);
}
void
ProcessProperties::SetDetachKeepsStopped (bool stop)
{
const uint32_t idx = ePropertyDetachKeepsStopped;
m_collection_sp->SetPropertyAtIndexAsBoolean(NULL, idx, stop);
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
void
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfo::Dump (Stream &s, Platform *platform) const
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
const char *cstr;
if (m_pid != LLDB_INVALID_PROCESS_ID)
s.Printf (" pid = %" PRIu64 "\n", m_pid);
if (m_parent_pid != LLDB_INVALID_PROCESS_ID)
s.Printf (" parent = %" PRIu64 "\n", m_parent_pid);
if (m_executable)
{
s.Printf (" name = %s\n", m_executable.GetFilename().GetCString());
s.PutCString (" file = ");
m_executable.Dump(&s);
s.EOL();
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const uint32_t argc = m_arguments.GetArgumentCount();
if (argc > 0)
{
for (uint32_t i=0; i<argc; i++)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const char *arg = m_arguments.GetArgumentAtIndex(i);
if (i < 10)
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf (" arg[%u] = %s\n", i, arg);
else
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("arg[%u] = %s\n", i, arg);
}
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const uint32_t envc = m_environment.GetArgumentCount();
if (envc > 0)
{
for (uint32_t i=0; i<envc; i++)
{
const char *env = m_environment.GetArgumentAtIndex(i);
if (i < 10)
s.Printf (" env[%u] = %s\n", i, env);
else
s.Printf ("env[%u] = %s\n", i, env);
}
}
if (m_arch.IsValid())
s.Printf (" arch = %s\n", m_arch.GetTriple().str().c_str());
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (m_uid != UINT32_MAX)
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetUserName (m_uid);
s.Printf (" uid = %-5u (%s)\n", m_uid, cstr ? cstr : "");
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (m_gid != UINT32_MAX)
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetGroupName (m_gid);
s.Printf (" gid = %-5u (%s)\n", m_gid, cstr ? cstr : "");
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (m_euid != UINT32_MAX)
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetUserName (m_euid);
s.Printf (" euid = %-5u (%s)\n", m_euid, cstr ? cstr : "");
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (m_egid != UINT32_MAX)
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetGroupName (m_egid);
s.Printf (" egid = %-5u (%s)\n", m_egid, cstr ? cstr : "");
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
}
void
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfo::DumpTableHeader (Stream &s, Platform *platform, bool show_args, bool verbose)
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const char *label;
if (show_args || verbose)
label = "ARGUMENTS";
else
label = "NAME";
if (verbose)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE %s\n", label);
s.PutCString ("====== ====== ========== ========== ========== ========== ======================== ============================\n");
}
else
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("PID PARENT USER ARCH %s\n", label);
s.PutCString ("====== ====== ========== ======= ============================\n");
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
void
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfo::DumpAsTableRow (Stream &s, Platform *platform, bool show_args, bool verbose) const
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
if (m_pid != LLDB_INVALID_PROCESS_ID)
{
const char *cstr;
s.Printf ("%-6" PRIu64 " %-6" PRIu64 " ", m_pid, m_parent_pid);
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
if (verbose)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetUserName (m_uid);
if (cstr && cstr[0]) // Watch for empty string that indicates lookup failed
s.Printf ("%-10s ", cstr);
else
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("%-10u ", m_uid);
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetGroupName (m_gid);
if (cstr && cstr[0]) // Watch for empty string that indicates lookup failed
s.Printf ("%-10s ", cstr);
else
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("%-10u ", m_gid);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetUserName (m_euid);
if (cstr && cstr[0]) // Watch for empty string that indicates lookup failed
s.Printf ("%-10s ", cstr);
else
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("%-10u ", m_euid);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cstr = platform->GetGroupName (m_egid);
if (cstr && cstr[0]) // Watch for empty string that indicates lookup failed
s.Printf ("%-10s ", cstr);
else
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.Printf ("%-10u ", m_egid);
s.Printf ("%-24s ", m_arch.IsValid() ? m_arch.GetTriple().str().c_str() : "");
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
else
{
s.Printf ("%-10s %-7d %s ",
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
platform->GetUserName (m_euid),
(int)m_arch.GetTriple().getArchName().size(),
m_arch.GetTriple().getArchName().data());
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (verbose || show_args)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const uint32_t argc = m_arguments.GetArgumentCount();
if (argc > 0)
{
for (uint32_t i=0; i<argc; i++)
{
if (i > 0)
s.PutChar (' ');
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s.PutCString (m_arguments.GetArgumentAtIndex(i));
}
}
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
else
{
s.PutCString (GetName());
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
s.EOL();
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
}
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
void
ProcessInfo::SetArguments (char const **argv, bool first_arg_is_executable)
{
m_arguments.SetArguments (argv);
// Is the first argument the executable?
if (first_arg_is_executable)
{
const char *first_arg = m_arguments.GetArgumentAtIndex (0);
if (first_arg)
{
// Yes the first argument is an executable, set it as the executable
// in the launch options. Don't resolve the file path as the path
// could be a remote platform path
const bool resolve = false;
m_executable.SetFile(first_arg, resolve);
}
}
}
void
ProcessInfo::SetArguments (const Args& args, bool first_arg_is_executable)
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
// Copy all arguments
m_arguments = args;
// Is the first argument the executable?
if (first_arg_is_executable)
{
const char *first_arg = m_arguments.GetArgumentAtIndex (0);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (first_arg)
{
// Yes the first argument is an executable, set it as the executable
// in the launch options. Don't resolve the file path as the path
// could be a remote platform path
const bool resolve = false;
m_executable.SetFile(first_arg, resolve);
}
}
}
void
ProcessLaunchInfo::FinalizeFileActions (Target *target, bool default_to_use_pty)
{
// If notthing was specified, then check the process for any default
// settings that were set with "settings set"
if (m_file_actions.empty())
{
if (m_flags.Test(eLaunchFlagDisableSTDIO))
{
AppendSuppressFileAction (STDIN_FILENO , true, false);
AppendSuppressFileAction (STDOUT_FILENO, false, true);
AppendSuppressFileAction (STDERR_FILENO, false, true);
}
else
{
// Check for any values that might have gotten set with any of:
// (lldb) settings set target.input-path
// (lldb) settings set target.output-path
// (lldb) settings set target.error-path
FileSpec in_path;
FileSpec out_path;
FileSpec err_path;
if (target)
{
in_path = target->GetStandardInputPath();
out_path = target->GetStandardOutputPath();
err_path = target->GetStandardErrorPath();
}
if (in_path || out_path || err_path)
{
char path[PATH_MAX];
if (in_path && in_path.GetPath(path, sizeof(path)))
AppendOpenFileAction(STDIN_FILENO, path, true, false);
if (out_path && out_path.GetPath(path, sizeof(path)))
AppendOpenFileAction(STDOUT_FILENO, path, false, true);
if (err_path && err_path.GetPath(path, sizeof(path)))
AppendOpenFileAction(STDERR_FILENO, path, false, true);
}
else if (default_to_use_pty)
{
if (m_pty.OpenFirstAvailableMaster (O_RDWR|O_NOCTTY, NULL, 0))
{
const char *slave_path = m_pty.GetSlaveName (NULL, 0);
AppendOpenFileAction(STDIN_FILENO, slave_path, true, false);
AppendOpenFileAction(STDOUT_FILENO, slave_path, false, true);
AppendOpenFileAction(STDERR_FILENO, slave_path, false, true);
}
}
}
}
}
bool
ProcessLaunchInfo::ConvertArgumentsForLaunchingInShell (Error &error,
bool localhost,
bool will_debug,
bool first_arg_is_full_shell_command,
int32_t num_resumes)
{
error.Clear();
if (GetFlags().Test (eLaunchFlagLaunchInShell))
{
const char *shell_executable = GetShell();
if (shell_executable)
{
char shell_resolved_path[PATH_MAX];
if (localhost)
{
FileSpec shell_filespec (shell_executable, true);
if (!shell_filespec.Exists())
{
// Resolve the path in case we just got "bash", "sh" or "tcsh"
if (!shell_filespec.ResolveExecutableLocation ())
{
error.SetErrorStringWithFormat("invalid shell path '%s'", shell_executable);
return false;
}
}
shell_filespec.GetPath (shell_resolved_path, sizeof(shell_resolved_path));
shell_executable = shell_resolved_path;
}
const char **argv = GetArguments().GetConstArgumentVector ();
if (argv == NULL || argv[0] == NULL)
return false;
Args shell_arguments;
std::string safe_arg;
shell_arguments.AppendArgument (shell_executable);
shell_arguments.AppendArgument ("-c");
StreamString shell_command;
if (will_debug)
{
// Add a modified PATH environment variable in case argv[0]
// is a relative path
const char *argv0 = argv[0];
if (argv0 && (argv0[0] != '/' && argv0[0] != '~'))
{
// We have a relative path to our executable which may not work if
// we just try to run "a.out" (without it being converted to "./a.out")
const char *working_dir = GetWorkingDirectory();
// Be sure to put quotes around PATH's value in case any paths have spaces...
std::string new_path("PATH=\"");
const size_t empty_path_len = new_path.size();
if (working_dir && working_dir[0])
{
new_path += working_dir;
}
else
{
char current_working_dir[PATH_MAX];
const char *cwd = getcwd(current_working_dir, sizeof(current_working_dir));
if (cwd && cwd[0])
new_path += cwd;
}
const char *curr_path = getenv("PATH");
if (curr_path)
{
if (new_path.size() > empty_path_len)
new_path += ':';
new_path += curr_path;
}
new_path += "\" ";
shell_command.PutCString(new_path.c_str());
}
shell_command.PutCString ("exec");
// Only Apple supports /usr/bin/arch being able to specify the architecture
if (GetArchitecture().IsValid())
{
shell_command.Printf(" /usr/bin/arch -arch %s", GetArchitecture().GetArchitectureName());
// Set the resume count to 2:
// 1 - stop in shell
// 2 - stop in /usr/bin/arch
// 3 - then we will stop in our program
SetResumeCount(num_resumes + 1);
}
else
{
// Set the resume count to 1:
// 1 - stop in shell
// 2 - then we will stop in our program
SetResumeCount(num_resumes);
}
}
if (first_arg_is_full_shell_command)
{
// There should only be one argument that is the shell command itself to be used as is
if (argv[0] && !argv[1])
shell_command.Printf("%s", argv[0]);
else
return false;
}
else
{
for (size_t i=0; argv[i] != NULL; ++i)
{
const char *arg = Args::GetShellSafeArgument (argv[i], safe_arg);
shell_command.Printf(" %s", arg);
}
}
shell_arguments.AppendArgument (shell_command.GetString().c_str());
m_executable.SetFile(shell_executable, false);
m_arguments = shell_arguments;
return true;
}
else
{
error.SetErrorString ("invalid shell path");
}
}
else
{
error.SetErrorString ("not launching in shell");
}
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 13:54:46 +08:00
bool
ProcessLaunchInfo::FileAction::Open (int fd, const char *path, bool read, bool write)
{
if ((read || write) && fd >= 0 && path && path[0])
{
m_action = eFileActionOpen;
m_fd = fd;
if (read && write)
m_arg = O_NOCTTY | O_CREAT | O_RDWR;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
else if (read)
m_arg = O_NOCTTY | O_RDONLY;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
else
m_arg = O_NOCTTY | O_CREAT | O_WRONLY;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
m_path.assign (path);
return true;
}
else
{
Clear();
}
return false;
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
bool
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessLaunchInfo::FileAction::Close (int fd)
{
Clear();
if (fd >= 0)
{
m_action = eFileActionClose;
m_fd = fd;
}
return m_fd >= 0;
}
bool
ProcessLaunchInfo::FileAction::Duplicate (int fd, int dup_fd)
{
Clear();
if (fd >= 0 && dup_fd >= 0)
{
m_action = eFileActionDuplicate;
m_fd = fd;
m_arg = dup_fd;
}
return m_fd >= 0;
}
#ifndef LLDB_DISABLE_POSIX
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
bool
ProcessLaunchInfo::FileAction::AddPosixSpawnFileAction (void *_file_actions,
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const FileAction *info,
Log *log,
Error& error)
{
if (info == NULL)
return false;
posix_spawn_file_actions_t *file_actions = reinterpret_cast<posix_spawn_file_actions_t *>(_file_actions);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
switch (info->m_action)
{
case eFileActionNone:
error.Clear();
break;
case eFileActionClose:
if (info->m_fd == -1)
error.SetErrorString ("invalid fd for posix_spawn_file_actions_addclose(...)");
else
{
error.SetError (::posix_spawn_file_actions_addclose (file_actions, info->m_fd),
eErrorTypePOSIX);
if (log && (error.Fail() || log))
error.PutToLog(log, "posix_spawn_file_actions_addclose (action=%p, fd=%i)",
file_actions, info->m_fd);
}
break;
case eFileActionDuplicate:
if (info->m_fd == -1)
error.SetErrorString ("invalid fd for posix_spawn_file_actions_adddup2(...)");
else if (info->m_arg == -1)
error.SetErrorString ("invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
else
{
error.SetError (::posix_spawn_file_actions_adddup2 (file_actions, info->m_fd, info->m_arg),
eErrorTypePOSIX);
if (log && (error.Fail() || log))
error.PutToLog(log, "posix_spawn_file_actions_adddup2 (action=%p, fd=%i, dup_fd=%i)",
file_actions, info->m_fd, info->m_arg);
}
break;
case eFileActionOpen:
if (info->m_fd == -1)
error.SetErrorString ("invalid fd in posix_spawn_file_actions_addopen(...)");
else
{
int oflag = info->m_arg;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
mode_t mode = 0;
if (oflag & O_CREAT)
mode = 0640;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
error.SetError (::posix_spawn_file_actions_addopen (file_actions,
info->m_fd,
info->m_path.c_str(),
oflag,
mode),
eErrorTypePOSIX);
if (error.Fail() || log)
error.PutToLog(log,
"posix_spawn_file_actions_addopen (action=%p, fd=%i, path='%s', oflag=%i, mode=%i)",
file_actions, info->m_fd, info->m_path.c_str(), oflag, mode);
}
break;
}
return error.Success();
}
#endif
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Error
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
ProcessLaunchCommandOptions::SetOptionValue (uint32_t option_idx, const char *option_arg)
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
Error error;
const int short_option = m_getopt_table[option_idx].val;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
switch (short_option)
{
case 's': // Stop at program entry point
launch_info.GetFlags().Set (eLaunchFlagStopAtEntry);
break;
case 'i': // STDIN for read only
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
ProcessLaunchInfo::FileAction action;
if (action.Open (STDIN_FILENO, option_arg, true, 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 13:54:46 +08:00
launch_info.AppendFileAction (action);
}
break;
case 'o': // Open STDOUT for write only
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
ProcessLaunchInfo::FileAction action;
if (action.Open (STDOUT_FILENO, option_arg, false, true))
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
launch_info.AppendFileAction (action);
}
break;
case 'e': // STDERR for write only
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
ProcessLaunchInfo::FileAction action;
if (action.Open (STDERR_FILENO, option_arg, false, true))
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
launch_info.AppendFileAction (action);
}
break;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
case 'p': // Process plug-in name
launch_info.SetProcessPluginName (option_arg);
break;
case 'n': // Disable STDIO
{
ProcessLaunchInfo::FileAction action;
if (action.Open (STDIN_FILENO, "/dev/null", true, 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 13:54:46 +08:00
launch_info.AppendFileAction (action);
if (action.Open (STDOUT_FILENO, "/dev/null", false, true))
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
launch_info.AppendFileAction (action);
if (action.Open (STDERR_FILENO, "/dev/null", false, true))
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
launch_info.AppendFileAction (action);
}
break;
case 'w':
launch_info.SetWorkingDirectory (option_arg);
break;
case 't': // Open process in new terminal window
launch_info.GetFlags().Set (eLaunchFlagLaunchInTTY);
break;
case 'a':
if (!launch_info.GetArchitecture().SetTriple (option_arg, m_interpreter.GetPlatform(true).get()))
launch_info.GetArchitecture().SetTriple (option_arg);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
break;
case 'A':
launch_info.GetFlags().Set (eLaunchFlagDisableASLR);
break;
case 'c':
if (option_arg && option_arg[0])
launch_info.SetShell (option_arg);
else
launch_info.SetShell (LLDB_DEFAULT_SHELL);
break;
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
case 'v':
launch_info.GetEnvironmentEntries().AppendArgument(option_arg);
break;
default:
error.SetErrorStringWithFormat("unrecognized short option character '%c'", short_option);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
break;
}
return error;
}
OptionDefinition
ProcessLaunchCommandOptions::g_option_table[] =
{
2013-09-06 00:42:23 +08:00
{ LLDB_OPT_SET_ALL, false, "stop-at-entry", 's', OptionParser::eNoArgument, NULL, 0, eArgTypeNone, "Stop at the entry point of the program when launching a process."},
{ LLDB_OPT_SET_ALL, false, "disable-aslr", 'A', OptionParser::eNoArgument, NULL, 0, eArgTypeNone, "Disable address space layout randomization when launching a process."},
{ LLDB_OPT_SET_ALL, false, "plugin", 'p', OptionParser::eRequiredArgument, NULL, 0, eArgTypePlugin, "Name of the process plugin you want to use."},
{ LLDB_OPT_SET_ALL, false, "working-dir", 'w', OptionParser::eRequiredArgument, NULL, 0, eArgTypeDirectoryName, "Set the current working directory to <path> when running the inferior."},
{ LLDB_OPT_SET_ALL, false, "arch", 'a', OptionParser::eRequiredArgument, NULL, 0, eArgTypeArchitecture, "Set the architecture for the process to launch when ambiguous."},
{ LLDB_OPT_SET_ALL, false, "environment", 'v', OptionParser::eRequiredArgument, NULL, 0, eArgTypeNone, "Specify an environment variable name/value string (--environment NAME=VALUE). Can be specified multiple times for subsequent environment entries."},
{ LLDB_OPT_SET_ALL, false, "shell", 'c', OptionParser::eOptionalArgument, NULL, 0, eArgTypeFilename, "Run the process in a shell (not supported on all platforms)."},
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
2013-09-06 00:42:23 +08:00
{ LLDB_OPT_SET_1 , false, "stdin", 'i', OptionParser::eRequiredArgument, NULL, 0, eArgTypeFilename, "Redirect stdin for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stdout", 'o', OptionParser::eRequiredArgument, NULL, 0, eArgTypeFilename, "Redirect stdout for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stderr", 'e', OptionParser::eRequiredArgument, NULL, 0, eArgTypeFilename, "Redirect stderr for the process to <filename>."},
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
2013-09-06 00:42:23 +08:00
{ LLDB_OPT_SET_2 , false, "tty", 't', OptionParser::eNoArgument, NULL, 0, eArgTypeNone, "Start the process in a terminal (not supported on all platforms)."},
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
2013-09-06 00:42:23 +08:00
{ LLDB_OPT_SET_3 , false, "no-stdio", 'n', OptionParser::eNoArgument, NULL, 0, eArgTypeNone, "Do not set up for terminal I/O to go to running process."},
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{ 0 , false, NULL, 0, 0, NULL, 0, eArgTypeNone, NULL }
};
bool
ProcessInstanceInfoMatch::NameMatches (const char *process_name) const
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
if (m_name_match_type == eNameMatchIgnore || process_name == NULL)
return true;
const char *match_name = m_match_info.GetName();
if (!match_name)
return true;
return lldb_private::NameMatches (process_name, m_name_match_type, match_name);
}
bool
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfoMatch::Matches (const ProcessInstanceInfo &proc_info) const
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
if (!NameMatches (proc_info.GetName()))
return false;
if (m_match_info.ProcessIDIsValid() &&
m_match_info.GetProcessID() != proc_info.GetProcessID())
return false;
if (m_match_info.ParentProcessIDIsValid() &&
m_match_info.GetParentProcessID() != proc_info.GetParentProcessID())
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 13:54:46 +08:00
if (m_match_info.UserIDIsValid () &&
m_match_info.GetUserID() != proc_info.GetUserID())
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
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 13:54:46 +08:00
if (m_match_info.GroupIDIsValid () &&
m_match_info.GetGroupID() != proc_info.GetGroupID())
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
return false;
if (m_match_info.EffectiveUserIDIsValid () &&
m_match_info.GetEffectiveUserID() != proc_info.GetEffectiveUserID())
return false;
if (m_match_info.EffectiveGroupIDIsValid () &&
m_match_info.GetEffectiveGroupID() != proc_info.GetEffectiveGroupID())
return false;
if (m_match_info.GetArchitecture().IsValid() &&
!m_match_info.GetArchitecture().IsCompatibleMatch(proc_info.GetArchitecture()))
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
return false;
return true;
}
bool
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfoMatch::MatchAllProcesses () const
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
if (m_name_match_type != eNameMatchIgnore)
return false;
if (m_match_info.ProcessIDIsValid())
return false;
if (m_match_info.ParentProcessIDIsValid())
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 13:54:46 +08:00
if (m_match_info.UserIDIsValid ())
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
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 13:54:46 +08:00
if (m_match_info.GroupIDIsValid ())
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
return false;
if (m_match_info.EffectiveUserIDIsValid ())
return false;
if (m_match_info.EffectiveGroupIDIsValid ())
return false;
if (m_match_info.GetArchitecture().IsValid())
return false;
if (m_match_all_users)
return false;
return true;
}
void
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfoMatch::Clear()
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
{
m_match_info.Clear();
m_name_match_type = eNameMatchIgnore;
m_match_all_users = false;
}
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
ProcessSP
Process::FindPlugin (Target &target, const char *plugin_name, Listener &listener, const FileSpec *crash_file_path)
{
static uint32_t g_process_unique_id = 0;
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
ProcessSP process_sp;
ProcessCreateInstance create_callback = NULL;
if (plugin_name)
{
ConstString const_plugin_name(plugin_name);
create_callback = PluginManager::GetProcessCreateCallbackForPluginName (const_plugin_name);
if (create_callback)
{
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
process_sp = create_callback(target, listener, crash_file_path);
if (process_sp)
{
if (process_sp->CanDebug(target, true))
{
process_sp->m_process_unique_id = ++g_process_unique_id;
}
else
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
process_sp.reset();
}
}
}
else
{
for (uint32_t idx = 0; (create_callback = PluginManager::GetProcessCreateCallbackAtIndex(idx)) != NULL; ++idx)
{
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
process_sp = create_callback(target, listener, crash_file_path);
if (process_sp)
{
if (process_sp->CanDebug(target, false))
{
process_sp->m_process_unique_id = ++g_process_unique_id;
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
break;
}
else
process_sp.reset();
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
}
}
}
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
return process_sp;
}
ConstString &
Process::GetStaticBroadcasterClass ()
{
static ConstString class_name ("lldb.process");
return class_name;
}
//----------------------------------------------------------------------
// Process constructor
//----------------------------------------------------------------------
Process::Process(Target &target, Listener &listener) :
ProcessProperties (false),
UserID (LLDB_INVALID_PROCESS_ID),
Broadcaster (&(target.GetDebugger()), "lldb.process"),
m_target (target),
m_public_state (eStateUnloaded),
m_private_state (eStateUnloaded),
m_private_state_broadcaster (NULL, "lldb.process.internal_state_broadcaster"),
m_private_state_control_broadcaster (NULL, "lldb.process.internal_state_control_broadcaster"),
m_private_state_listener ("lldb.process.internal_state_listener"),
m_private_state_control_wait(),
m_private_state_thread (LLDB_INVALID_HOST_THREAD),
m_mod_id (),
m_process_unique_id(0),
m_thread_index_id (0),
m_thread_id_to_index_id_map (),
m_exit_status (-1),
m_exit_string (),
m_thread_mutex (Mutex::eMutexTypeRecursive),
m_thread_list_real (this),
m_thread_list (this),
m_extended_thread_list (this),
m_extended_thread_stop_id (0),
m_queue_list (this),
m_queue_list_stop_id (0),
m_notifications (),
2010-11-18 13:57:03 +08:00
m_image_tokens (),
m_listener (listener),
m_breakpoint_site_list (),
m_dynamic_checkers_ap (),
m_unix_signals (),
2010-11-18 13:57:03 +08:00
m_abi_sp (),
m_process_input_reader (),
Put more smarts into the RegisterContext base class. Now the base class has a method: void RegisterContext::InvalidateIfNeeded (bool force); Each time this function is called, when "force" is false, it will only call the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if the register context's stop ID doesn't match that of the process. When the stop ID doesn't match, or "force" is true, the base class will clear its cached registers and the RegisterContext will update its stop ID to match that of the process. This helps make it easier to correctly flush the register context (possibly from multiple locations depending on when and where new registers are availabe) without inadvertently clearing the register cache when it doesn't need to be. Modified the ProcessGDBRemote plug-in to be much more efficient when it comes to: - caching the expedited registers in the stop reply packets (we were ignoring these before and it was causing us to read at least three registers every time we stopped that were already supplied in the stop reply packet). - When a thread has no stop reason, don't keep asking for the thread stopped info. Prior to this fix we would continually send a qThreadStopInfo packet over and over when any thread stop info was requested. We now note the stop ID that the stop info was requested for and avoid multiple requests. Cleaned up some of the expression code to not look for ClangExpressionVariable objects up by name since they are now shared pointers and we can just look for the exact pointer match and avoid possible errors. Fixed an bug in the ValueObject code that would cause children to not be displayed. llvm-svn: 123127
2011-01-10 05:07:35 +08:00
m_stdio_communication ("process.stdio"),
2010-11-18 13:57:03 +08:00
m_stdio_communication_mutex (Mutex::eMutexTypeRecursive),
m_stdout_data (),
m_stderr_data (),
m_profile_data_comm_mutex (Mutex::eMutexTypeRecursive),
m_profile_data (),
m_memory_cache (*this),
m_allocated_memory_cache (*this),
m_should_detach (false),
m_next_event_action_ap(),
m_public_run_lock (),
m_private_run_lock (),
m_currently_handling_event(false),
m_finalize_called(false),
m_clear_thread_plans_on_stop (false),
m_force_next_event_delivery(false),
m_last_broadcast_state (eStateInvalid),
m_destroy_in_process (false),
m_can_jit(eCanJITDontKnow)
{
CheckInWithManager ();
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
if (log)
log->Printf ("%p Process::Process()", this);
SetEventName (eBroadcastBitStateChanged, "state-changed");
SetEventName (eBroadcastBitInterrupt, "interrupt");
SetEventName (eBroadcastBitSTDOUT, "stdout-available");
SetEventName (eBroadcastBitSTDERR, "stderr-available");
SetEventName (eBroadcastBitProfileData, "profile-data-available");
m_private_state_control_broadcaster.SetEventName (eBroadcastInternalStateControlStop , "control-stop" );
m_private_state_control_broadcaster.SetEventName (eBroadcastInternalStateControlPause , "control-pause" );
m_private_state_control_broadcaster.SetEventName (eBroadcastInternalStateControlResume, "control-resume");
listener.StartListeningForEvents (this,
eBroadcastBitStateChanged |
eBroadcastBitInterrupt |
eBroadcastBitSTDOUT |
eBroadcastBitSTDERR |
eBroadcastBitProfileData);
m_private_state_listener.StartListeningForEvents(&m_private_state_broadcaster,
eBroadcastBitStateChanged |
eBroadcastBitInterrupt);
m_private_state_listener.StartListeningForEvents(&m_private_state_control_broadcaster,
eBroadcastInternalStateControlStop |
eBroadcastInternalStateControlPause |
eBroadcastInternalStateControlResume);
}
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
Process::~Process()
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
if (log)
log->Printf ("%p Process::~Process()", this);
StopPrivateStateThread();
}
const ProcessPropertiesSP &
Process::GetGlobalProperties()
{
static ProcessPropertiesSP g_settings_sp;
if (!g_settings_sp)
g_settings_sp.reset (new ProcessProperties (true));
return g_settings_sp;
}
void
Process::Finalize()
{
switch (GetPrivateState())
{
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
if (GetShouldDetach())
{
// FIXME: This will have to be a process setting:
bool keep_stopped = false;
Detach(keep_stopped);
}
else
Destroy();
break;
case eStateInvalid:
case eStateUnloaded:
case eStateDetached:
case eStateExited:
break;
}
// Clear our broadcaster before we proceed with destroying
Broadcaster::Clear();
// Do any cleanup needed prior to being destructed... Subclasses
// that override this method should call this superclass method as well.
// We need to destroy the loader before the derived Process class gets destroyed
// since it is very likely that undoing the loader will require access to the real process.
m_dynamic_checkers_ap.reset();
m_abi_sp.reset();
m_os_ap.reset();
m_system_runtime_ap.reset();
m_dyld_ap.reset();
m_jit_loaders_ap.reset();
m_thread_list_real.Destroy();
m_thread_list.Destroy();
m_extended_thread_list.Destroy();
m_queue_list.Clear();
m_queue_list_stop_id = 0;
std::vector<Notifications> empty_notifications;
m_notifications.swap(empty_notifications);
m_image_tokens.clear();
m_memory_cache.Clear();
m_allocated_memory_cache.Clear();
m_language_runtimes.clear();
m_next_event_action_ap.reset();
//#ifdef LLDB_CONFIGURATION_DEBUG
// StreamFile s(stdout, false);
// EventSP event_sp;
// while (m_private_state_listener.GetNextEvent(event_sp))
// {
// event_sp->Dump (&s);
// s.EOL();
// }
//#endif
// We have to be very careful here as the m_private_state_listener might
// contain events that have ProcessSP values in them which can keep this
// process around forever. These events need to be cleared out.
m_private_state_listener.Clear();
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.TrySetRunning(); // This will do nothing if already locked
m_public_run_lock.SetStopped();
m_private_run_lock.TrySetRunning(); // This will do nothing if already locked
m_private_run_lock.SetStopped();
m_finalize_called = true;
}
void
Process::RegisterNotificationCallbacks (const Notifications& callbacks)
{
m_notifications.push_back(callbacks);
if (callbacks.initialize != NULL)
callbacks.initialize (callbacks.baton, this);
}
bool
Process::UnregisterNotificationCallbacks(const Notifications& callbacks)
{
std::vector<Notifications>::iterator pos, end = m_notifications.end();
for (pos = m_notifications.begin(); pos != end; ++pos)
{
if (pos->baton == callbacks.baton &&
pos->initialize == callbacks.initialize &&
pos->process_state_changed == callbacks.process_state_changed)
{
m_notifications.erase(pos);
return true;
}
}
return false;
}
void
Process::SynchronouslyNotifyStateChanged (StateType state)
{
std::vector<Notifications>::iterator notification_pos, notification_end = m_notifications.end();
for (notification_pos = m_notifications.begin(); notification_pos != notification_end; ++notification_pos)
{
if (notification_pos->process_state_changed)
notification_pos->process_state_changed (notification_pos->baton, this, state);
}
}
// FIXME: We need to do some work on events before the general Listener sees them.
// For instance if we are continuing from a breakpoint, we need to ensure that we do
// the little "insert real insn, step & stop" trick. But we can't do that when the
// event is delivered by the broadcaster - since that is done on the thread that is
// waiting for new events, so if we needed more than one event for our handling, we would
// stall. So instead we do it when we fetch the event off of the queue.
//
StateType
Process::GetNextEvent (EventSP &event_sp)
{
StateType state = eStateInvalid;
if (m_listener.GetNextEventForBroadcaster (this, event_sp) && event_sp)
state = Process::ProcessEventData::GetStateFromEvent (event_sp.get());
return state;
}
StateType
Process::WaitForProcessToStop (const TimeValue *timeout, lldb::EventSP *event_sp_ptr, bool wait_always, Listener *hijack_listener)
{
// We can't just wait for a "stopped" event, because the stopped event may have restarted the target.
// We have to actually check each event, and in the case of a stopped event check the restarted flag
// on the event.
if (event_sp_ptr)
event_sp_ptr->reset();
StateType state = GetState();
// If we are exited or detached, we won't ever get back to any
// other valid state...
if (state == eStateDetached || state == eStateExited)
return state;
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s (timeout = %p)", __FUNCTION__, timeout);
if (!wait_always &&
StateIsStoppedState(state, true) &&
StateIsStoppedState(GetPrivateState(), true)) {
if (log)
log->Printf("Process::%s returning without waiting for events; process private and public states are already 'stopped'.",
__FUNCTION__);
return state;
}
while (state != eStateInvalid)
{
EventSP event_sp;
state = WaitForStateChangedEvents (timeout, event_sp, hijack_listener);
if (event_sp_ptr && event_sp)
*event_sp_ptr = event_sp;
switch (state)
{
case eStateCrashed:
case eStateDetached:
case eStateExited:
case eStateUnloaded:
// We need to toggle the run lock as this won't get done in
// SetPublicState() if the process is hijacked.
if (hijack_listener)
m_public_run_lock.SetStopped();
return state;
case eStateStopped:
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
continue;
else
{
// We need to toggle the run lock as this won't get done in
// SetPublicState() if the process is hijacked.
if (hijack_listener)
m_public_run_lock.SetStopped();
return state;
}
default:
continue;
}
}
return state;
}
StateType
Process::WaitForState
(
const TimeValue *timeout,
const StateType *match_states,
const uint32_t num_match_states
)
{
EventSP event_sp;
uint32_t i;
StateType state = GetState();
while (state != eStateInvalid)
{
// If we are exited or detached, we won't ever get back to any
// other valid state...
if (state == eStateDetached || state == eStateExited)
return state;
state = WaitForStateChangedEvents (timeout, event_sp, NULL);
for (i=0; i<num_match_states; ++i)
{
if (match_states[i] == state)
return state;
}
}
return state;
}
bool
Process::HijackProcessEvents (Listener *listener)
{
if (listener != NULL)
{
return HijackBroadcaster(listener, eBroadcastBitStateChanged | eBroadcastBitInterrupt);
}
else
return false;
}
void
Process::RestoreProcessEvents ()
{
RestoreBroadcaster();
}
bool
Process::HijackPrivateProcessEvents (Listener *listener)
{
if (listener != NULL)
{
return m_private_state_broadcaster.HijackBroadcaster(listener, eBroadcastBitStateChanged | eBroadcastBitInterrupt);
}
else
return false;
}
void
Process::RestorePrivateProcessEvents ()
{
m_private_state_broadcaster.RestoreBroadcaster();
}
StateType
Process::WaitForStateChangedEvents (const TimeValue *timeout, EventSP &event_sp, Listener *hijack_listener)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__, timeout);
Listener *listener = hijack_listener;
if (listener == NULL)
listener = &m_listener;
StateType state = eStateInvalid;
if (listener->WaitForEventForBroadcasterWithType (timeout,
this,
eBroadcastBitStateChanged | eBroadcastBitInterrupt,
event_sp))
{
if (event_sp && event_sp->GetType() == eBroadcastBitStateChanged)
state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
else if (log)
log->Printf ("Process::%s got no event or was interrupted.", __FUNCTION__);
}
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp) => %s",
__FUNCTION__,
timeout,
StateAsCString(state));
return state;
}
Event *
Process::PeekAtStateChangedEvents ()
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s...", __FUNCTION__);
Event *event_ptr;
event_ptr = m_listener.PeekAtNextEventForBroadcasterWithType (this,
eBroadcastBitStateChanged);
if (log)
{
if (event_ptr)
{
log->Printf ("Process::%s (event_ptr) => %s",
__FUNCTION__,
StateAsCString(ProcessEventData::GetStateFromEvent (event_ptr)));
}
else
{
log->Printf ("Process::%s no events found",
__FUNCTION__);
}
}
return event_ptr;
}
StateType
Process::WaitForStateChangedEventsPrivate (const TimeValue *timeout, EventSP &event_sp)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__, timeout);
StateType state = eStateInvalid;
if (m_private_state_listener.WaitForEventForBroadcasterWithType (timeout,
&m_private_state_broadcaster,
eBroadcastBitStateChanged | eBroadcastBitInterrupt,
event_sp))
if (event_sp && event_sp->GetType() == eBroadcastBitStateChanged)
state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
// This is a bit of a hack, but when we wait here we could very well return
// to the command-line, and that could disable the log, which would render the
// log we got above invalid.
if (log)
{
if (state == eStateInvalid)
log->Printf ("Process::%s (timeout = %p, event_sp) => TIMEOUT", __FUNCTION__, timeout);
else
log->Printf ("Process::%s (timeout = %p, event_sp) => %s", __FUNCTION__, timeout, StateAsCString(state));
}
return state;
}
bool
Process::WaitForEventsPrivate (const TimeValue *timeout, EventSP &event_sp, bool control_only)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__, timeout);
if (control_only)
return m_private_state_listener.WaitForEventForBroadcaster(timeout, &m_private_state_control_broadcaster, event_sp);
else
return m_private_state_listener.WaitForEvent(timeout, event_sp);
}
bool
Process::IsRunning () const
{
return StateIsRunningState (m_public_state.GetValue());
}
int
Process::GetExitStatus ()
{
if (m_public_state.GetValue() == eStateExited)
return m_exit_status;
return -1;
}
const char *
Process::GetExitDescription ()
{
if (m_public_state.GetValue() == eStateExited && !m_exit_string.empty())
return m_exit_string.c_str();
return NULL;
}
bool
Process::SetExitStatus (int status, const char *cstr)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::SetExitStatus (status=%i (0x%8.8x), description=%s%s%s)",
status, status,
cstr ? "\"" : "",
cstr ? cstr : "NULL",
cstr ? "\"" : "");
// We were already in the exited state
if (m_private_state.GetValue() == eStateExited)
{
if (log)
log->Printf("Process::SetExitStatus () ignoring exit status because state was already set to eStateExited");
return false;
}
m_exit_status = status;
if (cstr)
m_exit_string = cstr;
else
m_exit_string.clear();
DidExit ();
SetPrivateState (eStateExited);
return true;
}
// This static callback can be used to watch for local child processes on
// the current host. The the child process exits, the process will be
// found in the global target list (we want to be completely sure that the
// lldb_private::Process doesn't go away before we can deliver the signal.
bool
Process::SetProcessExitStatus (void *callback_baton,
lldb::pid_t pid,
bool exited,
int signo, // Zero for no signal
int exit_status // Exit value of process if signal is zero
)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::SetProcessExitStatus (baton=%p, pid=%" PRIu64 ", exited=%i, signal=%i, exit_status=%i)\n",
callback_baton,
pid,
exited,
signo,
exit_status);
if (exited)
{
TargetSP target_sp(Debugger::FindTargetWithProcessID (pid));
if (target_sp)
{
ProcessSP process_sp (target_sp->GetProcessSP());
if (process_sp)
{
const char *signal_cstr = NULL;
if (signo)
signal_cstr = process_sp->GetUnixSignals().GetSignalAsCString (signo);
process_sp->SetExitStatus (exit_status, signal_cstr);
}
}
return true;
}
return false;
}
void
Process::UpdateThreadListIfNeeded ()
{
const uint32_t stop_id = GetStopID();
if (m_thread_list.GetSize(false) == 0 || stop_id != m_thread_list.GetStopID())
{
const StateType state = GetPrivateState();
if (StateIsStoppedState (state, true))
{
Mutex::Locker locker (m_thread_list.GetMutex ());
// m_thread_list does have its own mutex, but we need to
// hold onto the mutex between the call to UpdateThreadList(...)
// and the os->UpdateThreadList(...) so it doesn't change on us
ThreadList &old_thread_list = m_thread_list;
ThreadList real_thread_list(this);
ThreadList new_thread_list(this);
// Always update the thread list with the protocol specific
// thread list, but only update if "true" is returned
if (UpdateThreadList (m_thread_list_real, real_thread_list))
{
// Don't call into the OperatingSystem to update the thread list if we are shutting down, since
// that may call back into the SBAPI's, requiring the API lock which is already held by whoever is
// shutting us down, causing a deadlock.
if (!m_destroy_in_process)
{
OperatingSystem *os = GetOperatingSystem ();
if (os)
{
// Clear any old backing threads where memory threads might have been
// backed by actual threads from the lldb_private::Process subclass
size_t num_old_threads = old_thread_list.GetSize(false);
for (size_t i=0; i<num_old_threads; ++i)
old_thread_list.GetThreadAtIndex(i, false)->ClearBackingThread();
// Now let the OperatingSystem plug-in update the thread list
os->UpdateThreadList (old_thread_list, // Old list full of threads created by OS plug-in
real_thread_list, // The actual thread list full of threads created by each lldb_private::Process subclass
new_thread_list); // The new thread list that we will show to the user that gets filled in
}
else
{
// No OS plug-in, the new thread list is the same as the real thread list
new_thread_list = real_thread_list;
}
}
m_thread_list_real.Update(real_thread_list);
m_thread_list.Update (new_thread_list);
m_thread_list.SetStopID (stop_id);
if (GetLastNaturalStopID () != m_extended_thread_stop_id)
{
// Clear any extended threads that we may have accumulated previously
m_extended_thread_list.Clear();
m_extended_thread_stop_id = GetLastNaturalStopID ();
m_queue_list.Clear();
m_queue_list_stop_id = GetLastNaturalStopID ();
}
}
}
}
}
void
Process::UpdateQueueListIfNeeded ()
{
if (m_system_runtime_ap.get())
{
if (m_queue_list.GetSize() == 0 || m_queue_list_stop_id != GetLastNaturalStopID())
{
const StateType state = GetPrivateState();
if (StateIsStoppedState (state, true))
{
m_system_runtime_ap->PopulateQueueList (m_queue_list);
m_queue_list_stop_id = GetLastNaturalStopID();
}
}
}
}
<rdar://problem/13010007> Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method: class OperatingSystemPlugin: def create_thread(self, tid, context): # Return a dictionary for a new thread to create it on demand This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used. Cleaned up the code in PythonDataObjects.cpp/h: - renamed all classes that started with PythonData* to be Python*. - renamed PythonArray to PythonList. Cleaned up the code to use inheritance where - Centralized the code that does ref counting in the PythonObject class to a single function. - Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object. - Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form: - PyObject * - const PythonObject & - const lldb::ScriptInterpreterObjectSP & Cleaned up code in ScriptInterpreterPython: - Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time. - Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized. llvm-svn: 172873
2013-01-19 07:41:08 +08:00
ThreadSP
Process::CreateOSPluginThread (lldb::tid_t tid, lldb::addr_t context)
{
OperatingSystem *os = GetOperatingSystem ();
if (os)
return os->CreateThread(tid, context);
return ThreadSP();
}
uint32_t
Process::GetNextThreadIndexID (uint64_t thread_id)
{
return AssignIndexIDToThread(thread_id);
}
bool
Process::HasAssignedIndexIDToThread(uint64_t thread_id)
{
std::map<uint64_t, uint32_t>::iterator iterator = m_thread_id_to_index_id_map.find(thread_id);
if (iterator == m_thread_id_to_index_id_map.end())
{
return false;
}
else
{
return true;
}
}
uint32_t
Process::AssignIndexIDToThread(uint64_t thread_id)
{
uint32_t result = 0;
std::map<uint64_t, uint32_t>::iterator iterator = m_thread_id_to_index_id_map.find(thread_id);
if (iterator == m_thread_id_to_index_id_map.end())
{
result = ++m_thread_index_id;
m_thread_id_to_index_id_map[thread_id] = result;
}
else
{
result = iterator->second;
}
return result;
}
StateType
Process::GetState()
{
// If any other threads access this we will need a mutex for it
return m_public_state.GetValue ();
}
void
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
Process::SetPublicState (StateType new_state, bool restarted)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
if (log)
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
log->Printf("Process::SetPublicState (state = %s, restarted = %i)", StateAsCString(new_state), restarted);
const StateType old_state = m_public_state.GetValue();
m_public_state.SetValue (new_state);
// On the transition from Run to Stopped, we unlock the writer end of the
// run lock. The lock gets locked in Resume, which is the public API
// to tell the program to run.
if (!IsHijackedForEvent(eBroadcastBitStateChanged))
{
if (new_state == eStateDetached)
{
if (log)
log->Printf("Process::SetPublicState (%s) -- unlocking run lock for detach", StateAsCString(new_state));
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
}
else
{
const bool old_state_is_stopped = StateIsStoppedState(old_state, false);
const bool new_state_is_stopped = StateIsStoppedState(new_state, false);
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if ((old_state_is_stopped != new_state_is_stopped))
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if (new_state_is_stopped && !restarted)
{
if (log)
log->Printf("Process::SetPublicState (%s) -- unlocking run lock", StateAsCString(new_state));
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
}
}
}
}
}
Error
Process::Resume ()
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::Resume -- locking run lock");
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (!m_public_run_lock.TrySetRunning())
{
Error error("Resume request failed - process still running.");
if (log)
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
log->Printf ("Process::Resume: -- TrySetRunning failed, not resuming.");
return error;
}
return PrivateResume();
}
StateType
Process::GetPrivateState ()
{
return m_private_state.GetValue();
}
void
Process::SetPrivateState (StateType new_state)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
bool state_changed = false;
if (log)
log->Printf("Process::SetPrivateState (%s)", StateAsCString(new_state));
Mutex::Locker thread_locker(m_thread_list.GetMutex());
Mutex::Locker locker(m_private_state.GetMutex());
const StateType old_state = m_private_state.GetValueNoLock ();
state_changed = old_state != new_state;
const bool old_state_is_stopped = StateIsStoppedState(old_state, false);
const bool new_state_is_stopped = StateIsStoppedState(new_state, false);
if (old_state_is_stopped != new_state_is_stopped)
{
if (new_state_is_stopped)
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_private_run_lock.SetStopped();
else
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_private_run_lock.SetRunning();
}
if (state_changed)
{
m_private_state.SetValueNoLock (new_state);
if (StateIsStoppedState(new_state, false))
{
// Note, this currently assumes that all threads in the list
// stop when the process stops. In the future we will want to
// support a debugging model where some threads continue to run
// while others are stopped. When that happens we will either need
// a way for the thread list to identify which threads are stopping
// or create a special thread list containing only threads which
// actually stopped.
//
// The process plugin is responsible for managing the actual
// behavior of the threads and should have stopped any threads
// that are going to stop before we get here.
m_thread_list.DidStop();
m_mod_id.BumpStopID();
m_memory_cache.Clear();
if (log)
log->Printf("Process::SetPrivateState (%s) stop_id = %u", StateAsCString(new_state), m_mod_id.GetStopID());
}
// Use our target to get a shared pointer to ourselves...
if (m_finalize_called && PrivateStateThreadIsValid() == false)
BroadcastEvent (eBroadcastBitStateChanged, new ProcessEventData (shared_from_this(), new_state));
else
m_private_state_broadcaster.BroadcastEvent (eBroadcastBitStateChanged, new ProcessEventData (shared_from_this(), new_state));
}
else
{
if (log)
log->Printf("Process::SetPrivateState (%s) state didn't change. Ignoring...", StateAsCString(new_state));
}
}
void
Process::SetRunningUserExpression (bool on)
{
m_mod_id.SetRunningUserExpression (on);
}
addr_t
Process::GetImageInfoAddress()
{
return LLDB_INVALID_ADDRESS;
}
//----------------------------------------------------------------------
// LoadImage
//
// This function provides a default implementation that works for most
// unix variants. Any Process subclasses that need to do shared library
// loading differently should override LoadImage and UnloadImage and
// do what is needed.
//----------------------------------------------------------------------
uint32_t
Process::LoadImage (const FileSpec &image_spec, Error &error)
{
char path[PATH_MAX];
image_spec.GetPath(path, sizeof(path));
DynamicLoader *loader = GetDynamicLoader();
if (loader)
{
error = loader->CanLoadImage();
if (error.Fail())
return LLDB_INVALID_IMAGE_TOKEN;
}
if (error.Success())
{
ThreadSP thread_sp(GetThreadList ().GetSelectedThread());
if (thread_sp)
{
StackFrameSP frame_sp (thread_sp->GetStackFrameAtIndex (0));
if (frame_sp)
{
ExecutionContext exe_ctx;
frame_sp->CalculateExecutionContext (exe_ctx);
EvaluateExpressionOptions expr_options;
expr_options.SetUnwindOnError(true);
expr_options.SetIgnoreBreakpoints(true);
expr_options.SetExecutionPolicy(eExecutionPolicyAlways);
StreamString expr;
expr.Printf("dlopen (\"%s\", 2)", path);
const char *prefix = "extern \"C\" void* dlopen (const char *path, int mode);\n";
lldb::ValueObjectSP result_valobj_sp;
Error expr_error;
ClangUserExpression::Evaluate (exe_ctx,
expr_options,
expr.GetData(),
prefix,
result_valobj_sp,
expr_error);
if (expr_error.Success())
{
error = result_valobj_sp->GetError();
if (error.Success())
{
Scalar scalar;
if (result_valobj_sp->ResolveValue (scalar))
{
addr_t image_ptr = scalar.ULongLong(LLDB_INVALID_ADDRESS);
if (image_ptr != 0 && image_ptr != LLDB_INVALID_ADDRESS)
{
uint32_t image_token = m_image_tokens.size();
m_image_tokens.push_back (image_ptr);
return image_token;
}
}
}
}
else
error = expr_error;
}
}
}
if (!error.AsCString())
error.SetErrorStringWithFormat("unable to load '%s'", path);
return LLDB_INVALID_IMAGE_TOKEN;
}
//----------------------------------------------------------------------
// UnloadImage
//
// This function provides a default implementation that works for most
// unix variants. Any Process subclasses that need to do shared library
// loading differently should override LoadImage and UnloadImage and
// do what is needed.
//----------------------------------------------------------------------
Error
Process::UnloadImage (uint32_t image_token)
{
Error error;
if (image_token < m_image_tokens.size())
{
const addr_t image_addr = m_image_tokens[image_token];
if (image_addr == LLDB_INVALID_ADDRESS)
{
error.SetErrorString("image already unloaded");
}
else
{
DynamicLoader *loader = GetDynamicLoader();
if (loader)
error = loader->CanLoadImage();
if (error.Success())
{
ThreadSP thread_sp(GetThreadList ().GetSelectedThread());
if (thread_sp)
{
StackFrameSP frame_sp (thread_sp->GetStackFrameAtIndex (0));
if (frame_sp)
{
ExecutionContext exe_ctx;
frame_sp->CalculateExecutionContext (exe_ctx);
EvaluateExpressionOptions expr_options;
expr_options.SetUnwindOnError(true);
expr_options.SetIgnoreBreakpoints(true);
expr_options.SetExecutionPolicy(eExecutionPolicyAlways);
StreamString expr;
expr.Printf("dlclose ((void *)0x%" PRIx64 ")", image_addr);
const char *prefix = "extern \"C\" int dlclose(void* handle);\n";
lldb::ValueObjectSP result_valobj_sp;
Error expr_error;
ClangUserExpression::Evaluate (exe_ctx,
expr_options,
expr.GetData(),
prefix,
result_valobj_sp,
expr_error);
if (result_valobj_sp->GetError().Success())
{
Scalar scalar;
if (result_valobj_sp->ResolveValue (scalar))
{
if (scalar.UInt(1))
{
error.SetErrorStringWithFormat("expression failed: \"%s\"", expr.GetData());
}
else
{
m_image_tokens[image_token] = LLDB_INVALID_ADDRESS;
}
}
}
else
{
error = result_valobj_sp->GetError();
}
}
}
}
}
}
else
{
error.SetErrorString("invalid image token");
}
return error;
}
const lldb::ABISP &
Process::GetABI()
{
if (!m_abi_sp)
m_abi_sp = ABI::FindPlugin(m_target.GetArchitecture());
return m_abi_sp;
}
LanguageRuntime *
Process::GetLanguageRuntime(lldb::LanguageType language, bool retry_if_null)
{
LanguageRuntimeCollection::iterator pos;
pos = m_language_runtimes.find (language);
if (pos == m_language_runtimes.end() || (retry_if_null && !(*pos).second))
{
lldb::LanguageRuntimeSP runtime_sp(LanguageRuntime::FindPlugin(this, language));
m_language_runtimes[language] = runtime_sp;
return runtime_sp.get();
}
else
return (*pos).second.get();
}
CPPLanguageRuntime *
Process::GetCPPLanguageRuntime (bool retry_if_null)
{
LanguageRuntime *runtime = GetLanguageRuntime(eLanguageTypeC_plus_plus, retry_if_null);
if (runtime != NULL && runtime->GetLanguageType() == eLanguageTypeC_plus_plus)
return static_cast<CPPLanguageRuntime *> (runtime);
return NULL;
}
ObjCLanguageRuntime *
Process::GetObjCLanguageRuntime (bool retry_if_null)
{
LanguageRuntime *runtime = GetLanguageRuntime(eLanguageTypeObjC, retry_if_null);
if (runtime != NULL && runtime->GetLanguageType() == eLanguageTypeObjC)
return static_cast<ObjCLanguageRuntime *> (runtime);
return NULL;
}
bool
Process::IsPossibleDynamicValue (ValueObject& in_value)
{
if (in_value.IsDynamic())
return false;
LanguageType known_type = in_value.GetObjectRuntimeLanguage();
if (known_type != eLanguageTypeUnknown && known_type != eLanguageTypeC)
{
LanguageRuntime *runtime = GetLanguageRuntime (known_type);
return runtime ? runtime->CouldHaveDynamicValue(in_value) : false;
}
LanguageRuntime *cpp_runtime = GetLanguageRuntime (eLanguageTypeC_plus_plus);
if (cpp_runtime && cpp_runtime->CouldHaveDynamicValue(in_value))
return true;
LanguageRuntime *objc_runtime = GetLanguageRuntime (eLanguageTypeObjC);
return objc_runtime ? objc_runtime->CouldHaveDynamicValue(in_value) : false;
}
BreakpointSiteList &
Process::GetBreakpointSiteList()
{
return m_breakpoint_site_list;
}
const BreakpointSiteList &
Process::GetBreakpointSiteList() const
{
return m_breakpoint_site_list;
}
void
Process::DisableAllBreakpointSites ()
{
m_breakpoint_site_list.ForEach([this](BreakpointSite *bp_site) -> void {
// bp_site->SetEnabled(true);
DisableBreakpointSite(bp_site);
});
}
Error
Process::ClearBreakpointSiteByID (lldb::user_id_t break_id)
{
Error error (DisableBreakpointSiteByID (break_id));
if (error.Success())
m_breakpoint_site_list.Remove(break_id);
return error;
}
Error
Process::DisableBreakpointSiteByID (lldb::user_id_t break_id)
{
Error error;
BreakpointSiteSP bp_site_sp = m_breakpoint_site_list.FindByID (break_id);
if (bp_site_sp)
{
if (bp_site_sp->IsEnabled())
error = DisableBreakpointSite (bp_site_sp.get());
}
else
{
error.SetErrorStringWithFormat("invalid breakpoint site ID: %" PRIu64, break_id);
}
return error;
}
Error
Process::EnableBreakpointSiteByID (lldb::user_id_t break_id)
{
Error error;
BreakpointSiteSP bp_site_sp = m_breakpoint_site_list.FindByID (break_id);
if (bp_site_sp)
{
if (!bp_site_sp->IsEnabled())
error = EnableBreakpointSite (bp_site_sp.get());
}
else
{
error.SetErrorStringWithFormat("invalid breakpoint site ID: %" PRIu64, break_id);
}
return error;
}
lldb::break_id_t
Process::CreateBreakpointSite (const BreakpointLocationSP &owner, bool use_hardware)
{
addr_t load_addr = LLDB_INVALID_ADDRESS;
bool show_error = true;
switch (GetState())
{
case eStateInvalid:
case eStateUnloaded:
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateDetached:
case eStateExited:
show_error = false;
break;
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
show_error = IsAlive();
break;
}
// Reset the IsIndirect flag here, in case the location changes from
// pointing to a indirect symbol to a regular symbol.
owner->SetIsIndirect (false);
if (owner->ShouldResolveIndirectFunctions())
{
Symbol *symbol = owner->GetAddress().CalculateSymbolContextSymbol();
if (symbol && symbol->IsIndirect())
{
Error error;
load_addr = ResolveIndirectFunction (&symbol->GetAddress(), error);
if (!error.Success() && show_error)
{
m_target.GetDebugger().GetErrorFile()->Printf ("warning: failed to resolve indirect function at 0x%" PRIx64 " for breakpoint %i.%i: %s\n",
symbol->GetAddress().GetLoadAddress(&m_target),
owner->GetBreakpoint().GetID(),
owner->GetID(),
error.AsCString() ? error.AsCString() : "unkown error");
return LLDB_INVALID_BREAK_ID;
}
Address resolved_address(load_addr);
load_addr = resolved_address.GetOpcodeLoadAddress (&m_target);
owner->SetIsIndirect(true);
}
else
load_addr = owner->GetAddress().GetOpcodeLoadAddress (&m_target);
}
else
load_addr = owner->GetAddress().GetOpcodeLoadAddress (&m_target);
if (load_addr != LLDB_INVALID_ADDRESS)
{
BreakpointSiteSP bp_site_sp;
// Look up this breakpoint site. If it exists, then add this new owner, otherwise
// create a new breakpoint site and add it.
bp_site_sp = m_breakpoint_site_list.FindByAddress (load_addr);
if (bp_site_sp)
{
bp_site_sp->AddOwner (owner);
owner->SetBreakpointSite (bp_site_sp);
return bp_site_sp->GetID();
}
else
{
bp_site_sp.reset (new BreakpointSite (&m_breakpoint_site_list, owner, load_addr, use_hardware));
if (bp_site_sp)
{
Error error = EnableBreakpointSite (bp_site_sp.get());
if (error.Success())
{
owner->SetBreakpointSite (bp_site_sp);
return m_breakpoint_site_list.Add (bp_site_sp);
}
else
{
if (show_error)
{
// Report error for setting breakpoint...
m_target.GetDebugger().GetErrorFile()->Printf ("warning: failed to set breakpoint site at 0x%" PRIx64 " for breakpoint %i.%i: %s\n",
load_addr,
owner->GetBreakpoint().GetID(),
owner->GetID(),
error.AsCString() ? error.AsCString() : "unkown error");
}
}
}
}
}
// We failed to enable the breakpoint
return LLDB_INVALID_BREAK_ID;
}
void
Process::RemoveOwnerFromBreakpointSite (lldb::user_id_t owner_id, lldb::user_id_t owner_loc_id, BreakpointSiteSP &bp_site_sp)
{
uint32_t num_owners = bp_site_sp->RemoveOwner (owner_id, owner_loc_id);
if (num_owners == 0)
{
// Don't try to disable the site if we don't have a live process anymore.
if (IsAlive())
DisableBreakpointSite (bp_site_sp.get());
m_breakpoint_site_list.RemoveByAddress(bp_site_sp->GetLoadAddress());
}
}
size_t
Process::RemoveBreakpointOpcodesFromBuffer (addr_t bp_addr, size_t size, uint8_t *buf) const
{
size_t bytes_removed = 0;
BreakpointSiteList bp_sites_in_range;
if (m_breakpoint_site_list.FindInRange (bp_addr, bp_addr + size, bp_sites_in_range))
{
bp_sites_in_range.ForEach([bp_addr, size, buf, &bytes_removed](BreakpointSite *bp_site) -> void {
if (bp_site->GetType() == BreakpointSite::eSoftware)
{
addr_t intersect_addr;
size_t intersect_size;
size_t opcode_offset;
if (bp_site->IntersectsRange(bp_addr, size, &intersect_addr, &intersect_size, &opcode_offset))
{
assert(bp_addr <= intersect_addr && intersect_addr < bp_addr + size);
assert(bp_addr < intersect_addr + intersect_size && intersect_addr + intersect_size <= bp_addr + size);
assert(opcode_offset + intersect_size <= bp_site->GetByteSize());
size_t buf_offset = intersect_addr - bp_addr;
::memcpy(buf + buf_offset, bp_site->GetSavedOpcodeBytes() + opcode_offset, intersect_size);
}
}
});
}
return bytes_removed;
}
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
size_t
Process::GetSoftwareBreakpointTrapOpcode (BreakpointSite* bp_site)
{
PlatformSP platform_sp (m_target.GetPlatform());
if (platform_sp)
return platform_sp->GetSoftwareBreakpointTrapOpcode (m_target, bp_site);
return 0;
}
Error
Process::EnableSoftwareBreakpoint (BreakpointSite *bp_site)
{
Error error;
assert (bp_site != NULL);
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
const addr_t bp_addr = bp_site->GetLoadAddress();
if (log)
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64, bp_site->GetID(), (uint64_t)bp_addr);
if (bp_site->IsEnabled())
{
if (log)
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- already enabled", bp_site->GetID(), (uint64_t)bp_addr);
return error;
}
if (bp_addr == LLDB_INVALID_ADDRESS)
{
error.SetErrorString("BreakpointSite contains an invalid load address.");
return error;
}
// Ask the lldb::Process subclass to fill in the correct software breakpoint
// trap for the breakpoint site
const size_t bp_opcode_size = GetSoftwareBreakpointTrapOpcode(bp_site);
if (bp_opcode_size == 0)
{
error.SetErrorStringWithFormat ("Process::GetSoftwareBreakpointTrapOpcode() returned zero, unable to get breakpoint trap for address 0x%" PRIx64, bp_addr);
}
else
{
const uint8_t * const bp_opcode_bytes = bp_site->GetTrapOpcodeBytes();
if (bp_opcode_bytes == NULL)
{
error.SetErrorString ("BreakpointSite doesn't contain a valid breakpoint trap opcode.");
return error;
}
// Save the original opcode by reading it
if (DoReadMemory(bp_addr, bp_site->GetSavedOpcodeBytes(), bp_opcode_size, error) == bp_opcode_size)
{
// Write a software breakpoint in place of the original opcode
if (DoWriteMemory(bp_addr, bp_opcode_bytes, bp_opcode_size, error) == bp_opcode_size)
{
uint8_t verify_bp_opcode_bytes[64];
if (DoReadMemory(bp_addr, verify_bp_opcode_bytes, bp_opcode_size, error) == bp_opcode_size)
{
if (::memcmp(bp_opcode_bytes, verify_bp_opcode_bytes, bp_opcode_size) == 0)
{
bp_site->SetEnabled(true);
bp_site->SetType (BreakpointSite::eSoftware);
if (log)
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- SUCCESS",
bp_site->GetID(),
(uint64_t)bp_addr);
}
else
error.SetErrorString("failed to verify the breakpoint trap in memory.");
}
else
error.SetErrorString("Unable to read memory to verify breakpoint trap.");
}
else
error.SetErrorString("Unable to write breakpoint trap to memory.");
}
else
error.SetErrorString("Unable to read memory at breakpoint address.");
}
if (log && error.Fail())
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- FAILED: %s",
bp_site->GetID(),
(uint64_t)bp_addr,
error.AsCString());
return error;
}
Error
Process::DisableSoftwareBreakpoint (BreakpointSite *bp_site)
{
Error error;
assert (bp_site != NULL);
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
addr_t bp_addr = bp_site->GetLoadAddress();
lldb::user_id_t breakID = bp_site->GetID();
if (log)
log->Printf ("Process::DisableSoftwareBreakpoint (breakID = %" PRIu64 ") addr = 0x%" PRIx64, breakID, (uint64_t)bp_addr);
if (bp_site->IsHardware())
{
error.SetErrorString("Breakpoint site is a hardware breakpoint.");
}
else if (bp_site->IsEnabled())
{
const size_t break_op_size = bp_site->GetByteSize();
const uint8_t * const break_op = bp_site->GetTrapOpcodeBytes();
if (break_op_size > 0)
{
// Clear a software breakoint instruction
uint8_t curr_break_op[8];
assert (break_op_size <= sizeof(curr_break_op));
bool break_op_found = false;
// Read the breakpoint opcode
if (DoReadMemory (bp_addr, curr_break_op, break_op_size, error) == break_op_size)
{
bool verify = false;
// Make sure we have the a breakpoint opcode exists at this address
if (::memcmp (curr_break_op, break_op, break_op_size) == 0)
{
break_op_found = true;
// We found a valid breakpoint opcode at this address, now restore
// the saved opcode.
if (DoWriteMemory (bp_addr, bp_site->GetSavedOpcodeBytes(), break_op_size, error) == break_op_size)
{
verify = true;
}
else
error.SetErrorString("Memory write failed when restoring original opcode.");
}
else
{
error.SetErrorString("Original breakpoint trap is no longer in memory.");
// Set verify to true and so we can check if the original opcode has already been restored
verify = true;
}
if (verify)
{
uint8_t verify_opcode[8];
assert (break_op_size < sizeof(verify_opcode));
// Verify that our original opcode made it back to the inferior
if (DoReadMemory (bp_addr, verify_opcode, break_op_size, error) == break_op_size)
{
// compare the memory we just read with the original opcode
if (::memcmp (bp_site->GetSavedOpcodeBytes(), verify_opcode, break_op_size) == 0)
{
// SUCCESS
bp_site->SetEnabled(false);
if (log)
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- SUCCESS", bp_site->GetID(), (uint64_t)bp_addr);
return error;
}
else
{
if (break_op_found)
error.SetErrorString("Failed to restore original opcode.");
}
}
else
error.SetErrorString("Failed to read memory to verify that breakpoint trap was restored.");
}
}
else
error.SetErrorString("Unable to read memory that should contain the breakpoint trap.");
}
}
else
{
if (log)
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- already disabled", bp_site->GetID(), (uint64_t)bp_addr);
return error;
}
if (log)
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- FAILED: %s",
bp_site->GetID(),
(uint64_t)bp_addr,
error.AsCString());
return error;
}
// Uncomment to verify memory caching works after making changes to caching code
//#define VERIFY_MEMORY_READS
size_t
Process::ReadMemory (addr_t addr, void *buf, size_t size, Error &error)
{
error.Clear();
if (!GetDisableMemoryCache())
{
#if defined (VERIFY_MEMORY_READS)
// Memory caching is enabled, with debug verification
if (buf && size)
{
// Uncomment the line below to make sure memory caching is working.
// I ran this through the test suite and got no assertions, so I am
// pretty confident this is working well. If any changes are made to
// memory caching, uncomment the line below and test your changes!
// Verify all memory reads by using the cache first, then redundantly
// reading the same memory from the inferior and comparing to make sure
// everything is exactly the same.
std::string verify_buf (size, '\0');
assert (verify_buf.size() == size);
const size_t cache_bytes_read = m_memory_cache.Read (this, addr, buf, size, error);
Error verify_error;
const size_t verify_bytes_read = ReadMemoryFromInferior (addr, const_cast<char *>(verify_buf.data()), verify_buf.size(), verify_error);
assert (cache_bytes_read == verify_bytes_read);
assert (memcmp(buf, verify_buf.data(), verify_buf.size()) == 0);
assert (verify_error.Success() == error.Success());
return cache_bytes_read;
}
return 0;
#else // !defined(VERIFY_MEMORY_READS)
// Memory caching is enabled, without debug verification
return m_memory_cache.Read (addr, buf, size, error);
#endif // defined (VERIFY_MEMORY_READS)
}
else
{
// Memory caching is disabled
return ReadMemoryFromInferior (addr, buf, size, error);
}
}
size_t
Process::ReadCStringFromMemory (addr_t addr, std::string &out_str, Error &error)
{
char buf[256];
out_str.clear();
addr_t curr_addr = addr;
while (1)
{
size_t length = ReadCStringFromMemory (curr_addr, buf, sizeof(buf), error);
if (length == 0)
break;
out_str.append(buf, length);
// If we got "length - 1" bytes, we didn't get the whole C string, we
// need to read some more characters
if (length == sizeof(buf) - 1)
curr_addr += length;
else
break;
}
return out_str.size();
}
size_t
Process::ReadStringFromMemory (addr_t addr, char *dst, size_t max_bytes, Error &error,
size_t type_width)
{
size_t total_bytes_read = 0;
if (dst && max_bytes && type_width && max_bytes >= type_width)
{
// Ensure a null terminator independent of the number of bytes that is read.
memset (dst, 0, max_bytes);
size_t bytes_left = max_bytes - type_width;
const char terminator[4] = {'\0', '\0', '\0', '\0'};
assert(sizeof(terminator) >= type_width &&
"Attempting to validate a string with more than 4 bytes per character!");
addr_t curr_addr = addr;
const size_t cache_line_size = m_memory_cache.GetMemoryCacheLineSize();
char *curr_dst = dst;
error.Clear();
while (bytes_left > 0 && error.Success())
{
addr_t cache_line_bytes_left = cache_line_size - (curr_addr % cache_line_size);
addr_t bytes_to_read = std::min<addr_t>(bytes_left, cache_line_bytes_left);
size_t bytes_read = ReadMemory (curr_addr, curr_dst, bytes_to_read, error);
if (bytes_read == 0)
break;
// Search for a null terminator of correct size and alignment in bytes_read
size_t aligned_start = total_bytes_read - total_bytes_read % type_width;
for (size_t i = aligned_start; i + type_width <= total_bytes_read + bytes_read; i += type_width)
if (::strncmp(&dst[i], terminator, type_width) == 0)
{
error.Clear();
return i;
}
total_bytes_read += bytes_read;
curr_dst += bytes_read;
curr_addr += bytes_read;
bytes_left -= bytes_read;
}
}
else
{
if (max_bytes)
error.SetErrorString("invalid arguments");
}
return total_bytes_read;
}
// Deprecated in favor of ReadStringFromMemory which has wchar support and correct code to find
// null terminators.
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
size_t
Process::ReadCStringFromMemory (addr_t addr, char *dst, size_t dst_max_len, Error &result_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 13:54:46 +08:00
{
size_t total_cstr_len = 0;
if (dst && dst_max_len)
{
result_error.Clear();
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
// NULL out everything just to be safe
memset (dst, 0, dst_max_len);
Error error;
addr_t curr_addr = addr;
const size_t cache_line_size = m_memory_cache.GetMemoryCacheLineSize();
size_t bytes_left = dst_max_len - 1;
char *curr_dst = dst;
while (bytes_left > 0)
{
addr_t cache_line_bytes_left = cache_line_size - (curr_addr % cache_line_size);
addr_t bytes_to_read = std::min<addr_t>(bytes_left, cache_line_bytes_left);
size_t bytes_read = ReadMemory (curr_addr, curr_dst, bytes_to_read, error);
if (bytes_read == 0)
{
result_error = 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 13:54:46 +08:00
dst[total_cstr_len] = '\0';
break;
}
const size_t len = strlen(curr_dst);
total_cstr_len += len;
if (len < bytes_to_read)
break;
curr_dst += bytes_read;
curr_addr += bytes_read;
bytes_left -= bytes_read;
}
}
else
{
if (dst == NULL)
result_error.SetErrorString("invalid arguments");
else
result_error.Clear();
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
return total_cstr_len;
}
size_t
Process::ReadMemoryFromInferior (addr_t addr, void *buf, size_t size, Error &error)
{
if (buf == NULL || size == 0)
return 0;
size_t bytes_read = 0;
uint8_t *bytes = (uint8_t *)buf;
while (bytes_read < size)
{
const size_t curr_size = size - bytes_read;
const size_t curr_bytes_read = DoReadMemory (addr + bytes_read,
bytes + bytes_read,
curr_size,
error);
bytes_read += curr_bytes_read;
if (curr_bytes_read == curr_size || curr_bytes_read == 0)
break;
}
// Replace any software breakpoint opcodes that fall into this range back
// into "buf" before we return
if (bytes_read > 0)
RemoveBreakpointOpcodesFromBuffer (addr, bytes_read, (uint8_t *)buf);
return bytes_read;
}
uint64_t
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
Process::ReadUnsignedIntegerFromMemory (lldb::addr_t vm_addr, size_t integer_byte_size, uint64_t fail_value, Error &error)
{
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
Scalar scalar;
if (ReadScalarIntegerFromMemory(vm_addr, integer_byte_size, false, scalar, error))
return scalar.ULongLong(fail_value);
return fail_value;
}
addr_t
Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error)
{
Scalar scalar;
if (ReadScalarIntegerFromMemory(vm_addr, GetAddressByteSize(), false, scalar, error))
return scalar.ULongLong(LLDB_INVALID_ADDRESS);
return LLDB_INVALID_ADDRESS;
}
bool
Process::WritePointerToMemory (lldb::addr_t vm_addr,
lldb::addr_t ptr_value,
Error &error)
{
Scalar scalar;
const uint32_t addr_byte_size = GetAddressByteSize();
if (addr_byte_size <= 4)
scalar = (uint32_t)ptr_value;
else
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
scalar = ptr_value;
return WriteScalarToMemory(vm_addr, scalar, addr_byte_size, error) == addr_byte_size;
}
size_t
Process::WriteMemoryPrivate (addr_t addr, const void *buf, size_t size, Error &error)
{
size_t bytes_written = 0;
const uint8_t *bytes = (const uint8_t *)buf;
while (bytes_written < size)
{
const size_t curr_size = size - bytes_written;
const size_t curr_bytes_written = DoWriteMemory (addr + bytes_written,
bytes + bytes_written,
curr_size,
error);
bytes_written += curr_bytes_written;
if (curr_bytes_written == curr_size || curr_bytes_written == 0)
break;
}
return bytes_written;
}
size_t
Process::WriteMemory (addr_t addr, const void *buf, size_t size, Error &error)
{
#if defined (ENABLE_MEMORY_CACHING)
m_memory_cache.Flush (addr, size);
#endif
if (buf == NULL || size == 0)
return 0;
m_mod_id.BumpMemoryID();
// We need to write any data that would go where any current software traps
// (enabled software breakpoints) any software traps (breakpoints) that we
// may have placed in our tasks memory.
BreakpointSiteList bp_sites_in_range;
if (m_breakpoint_site_list.FindInRange (addr, addr + size, bp_sites_in_range))
{
// No breakpoint sites overlap
if (bp_sites_in_range.IsEmpty())
return WriteMemoryPrivate (addr, buf, size, error);
else
{
const uint8_t *ubuf = (const uint8_t *)buf;
uint64_t bytes_written = 0;
bp_sites_in_range.ForEach([this, addr, size, &bytes_written, &ubuf, &error](BreakpointSite *bp) -> void {
if (error.Success())
{
addr_t intersect_addr;
size_t intersect_size;
size_t opcode_offset;
const bool intersects = bp->IntersectsRange(addr, size, &intersect_addr, &intersect_size, &opcode_offset);
assert(intersects);
assert(addr <= intersect_addr && intersect_addr < addr + size);
assert(addr < intersect_addr + intersect_size && intersect_addr + intersect_size <= addr + size);
assert(opcode_offset + intersect_size <= bp->GetByteSize());
// Check for bytes before this breakpoint
const addr_t curr_addr = addr + bytes_written;
if (intersect_addr > curr_addr)
{
// There are some bytes before this breakpoint that we need to
// just write to memory
size_t curr_size = intersect_addr - curr_addr;
size_t curr_bytes_written = WriteMemoryPrivate (curr_addr,
ubuf + bytes_written,
curr_size,
error);
bytes_written += curr_bytes_written;
if (curr_bytes_written != curr_size)
{
// We weren't able to write all of the requested bytes, we
// are done looping and will return the number of bytes that
// we have written so far.
if (error.Success())
error.SetErrorToGenericError();
}
}
// Now write any bytes that would cover up any software breakpoints
// directly into the breakpoint opcode buffer
::memcpy(bp->GetSavedOpcodeBytes() + opcode_offset, ubuf + bytes_written, intersect_size);
bytes_written += intersect_size;
}
});
if (bytes_written < size)
bytes_written += WriteMemoryPrivate (addr + bytes_written,
ubuf + bytes_written,
size - bytes_written,
error);
}
}
else
{
return WriteMemoryPrivate (addr, buf, size, error);
}
// Write any remaining bytes after the last breakpoint if we have any left
return 0; //bytes_written;
}
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
size_t
Process::WriteScalarToMemory (addr_t addr, const Scalar &scalar, size_t byte_size, Error &error)
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
{
if (byte_size == UINT32_MAX)
byte_size = scalar.GetByteSize();
if (byte_size > 0)
{
uint8_t buf[32];
const size_t mem_size = scalar.GetAsMemoryData (buf, byte_size, GetByteOrder(), error);
if (mem_size > 0)
return WriteMemory(addr, buf, mem_size, error);
else
error.SetErrorString ("failed to get scalar as memory data");
}
else
{
error.SetErrorString ("invalid scalar value");
}
return 0;
}
size_t
Process::ReadScalarIntegerFromMemory (addr_t addr,
uint32_t byte_size,
bool is_signed,
Scalar &scalar,
Error &error)
{
uint64_t uval = 0;
if (byte_size == 0)
{
error.SetErrorString ("byte size is zero");
}
else if (byte_size & (byte_size - 1))
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
{
error.SetErrorStringWithFormat ("byte size %u is not a power of 2", byte_size);
}
else if (byte_size <= sizeof(uval))
{
const size_t bytes_read = ReadMemory (addr, &uval, byte_size, error);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
if (bytes_read == byte_size)
{
DataExtractor data (&uval, sizeof(uval), GetByteOrder(), GetAddressByteSize());
lldb::offset_t offset = 0;
if (byte_size <= 4)
scalar = data.GetMaxU32 (&offset, byte_size);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
else
scalar = data.GetMaxU64 (&offset, byte_size);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
if (is_signed)
scalar.SignExtend(byte_size * 8);
return bytes_read;
}
}
else
{
error.SetErrorStringWithFormat ("byte size of %u is too large for integer scalar type", byte_size);
}
return 0;
}
#define USE_ALLOCATE_MEMORY_CACHE 1
addr_t
Process::AllocateMemory(size_t size, uint32_t permissions, Error &error)
{
if (GetPrivateState() != eStateStopped)
return LLDB_INVALID_ADDRESS;
#if defined (USE_ALLOCATE_MEMORY_CACHE)
return m_allocated_memory_cache.AllocateMemory(size, permissions, error);
#else
addr_t allocated_addr = DoAllocateMemory (size, permissions, error);
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::AllocateMemory(size=%" PRIu64 ", permissions=%s) => 0x%16.16" PRIx64 " (m_stop_id = %u m_memory_id = %u)",
(uint64_t)size,
GetPermissionsAsCString (permissions),
(uint64_t)allocated_addr,
m_mod_id.GetStopID(),
m_mod_id.GetMemoryID());
return allocated_addr;
#endif
}
bool
Process::CanJIT ()
{
if (m_can_jit == eCanJITDontKnow)
{
Error err;
uint64_t allocated_memory = AllocateMemory(8,
ePermissionsReadable | ePermissionsWritable | ePermissionsExecutable,
err);
if (err.Success())
m_can_jit = eCanJITYes;
else
m_can_jit = eCanJITNo;
DeallocateMemory (allocated_memory);
}
return m_can_jit == eCanJITYes;
}
void
Process::SetCanJIT (bool can_jit)
{
m_can_jit = (can_jit ? eCanJITYes : eCanJITNo);
}
Error
Process::DeallocateMemory (addr_t ptr)
{
Error error;
#if defined (USE_ALLOCATE_MEMORY_CACHE)
if (!m_allocated_memory_cache.DeallocateMemory(ptr))
{
error.SetErrorStringWithFormat ("deallocation of memory at 0x%" PRIx64 " failed.", (uint64_t)ptr);
}
#else
error = DoDeallocateMemory (ptr);
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::DeallocateMemory(addr=0x%16.16" PRIx64 ") => err = %s (m_stop_id = %u, m_memory_id = %u)",
ptr,
error.AsCString("SUCCESS"),
m_mod_id.GetStopID(),
m_mod_id.GetMemoryID());
#endif
return error;
}
ModuleSP
Process::ReadModuleFromMemory (const FileSpec& file_spec,
lldb::addr_t header_addr,
size_t size_to_read)
{
ModuleSP module_sp (new Module (file_spec, ArchSpec()));
if (module_sp)
{
Error error;
ObjectFile *objfile = module_sp->GetMemoryObjectFile (shared_from_this(), header_addr, error, size_to_read);
if (objfile)
return module_sp;
}
return ModuleSP();
}
Error
Process::EnableWatchpoint (Watchpoint *watchpoint, bool notify)
{
Error error;
error.SetErrorString("watchpoints are not supported");
return error;
}
Error
Process::DisableWatchpoint (Watchpoint *watchpoint, bool notify)
{
Error error;
error.SetErrorString("watchpoints are not supported");
return error;
}
StateType
Process::WaitForProcessStopPrivate (const TimeValue *timeout, EventSP &event_sp)
{
StateType state;
// Now wait for the process to launch and return control to us, and then
// call DidLaunch:
while (1)
{
event_sp.reset();
state = WaitForStateChangedEventsPrivate (timeout, event_sp);
if (StateIsStoppedState(state, false))
break;
// If state is invalid, then we timed out
if (state == eStateInvalid)
break;
if (event_sp)
HandlePrivateEvent (event_sp);
}
return state;
}
Error
Process::Launch (ProcessLaunchInfo &launch_info)
{
Error error;
m_abi_sp.reset();
m_dyld_ap.reset();
m_jit_loaders_ap.reset();
m_system_runtime_ap.reset();
m_os_ap.reset();
m_process_input_reader.reset();
Module *exe_module = m_target.GetExecutableModulePointer();
if (exe_module)
{
char local_exec_file_path[PATH_MAX];
char platform_exec_file_path[PATH_MAX];
exe_module->GetFileSpec().GetPath(local_exec_file_path, sizeof(local_exec_file_path));
exe_module->GetPlatformFileSpec().GetPath(platform_exec_file_path, sizeof(platform_exec_file_path));
if (exe_module->GetFileSpec().Exists())
{
// Install anything that might need to be installed prior to launching.
// For host systems, this will do nothing, but if we are connected to a
// remote platform it will install any needed binaries
error = GetTarget().Install(&launch_info);
if (error.Fail())
return error;
if (PrivateStateThreadIsValid ())
PausePrivateStateThread ();
error = WillLaunch (exe_module);
if (error.Success())
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateLaunching, restarted);
m_should_detach = false;
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
{
// Now launch using these arguments.
error = DoLaunch (exe_module, launch_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
if (error.Fail())
{
if (GetID() != LLDB_INVALID_PROCESS_ID)
{
SetID (LLDB_INVALID_PROCESS_ID);
const char *error_string = error.AsCString();
if (error_string == NULL)
error_string = "launch failed";
SetExitStatus (-1, error_string);
}
}
else
{
EventSP event_sp;
TimeValue timeout_time;
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(10);
StateType state = WaitForProcessStopPrivate(&timeout_time, event_sp);
if (state == eStateInvalid || event_sp.get() == NULL)
{
// We were able to launch the process, but we failed to
// catch the initial stop.
SetExitStatus (0, "failed to catch stop after launch");
Destroy();
}
else if (state == eStateStopped || state == eStateCrashed)
{
DidLaunch ();
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidLaunch();
GetJITLoaders().DidLaunch();
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
system_runtime->DidLaunch();
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
// This delays passing the stopped event to listeners till DidLaunch gets
// a chance to complete...
HandlePrivateEvent (event_sp);
if (PrivateStateThreadIsValid ())
ResumePrivateStateThread ();
else
StartPrivateStateThread ();
}
else if (state == eStateExited)
{
// We exited while trying to launch somehow. Don't call DidLaunch as that's
// not likely to work, and return an invalid pid.
HandlePrivateEvent (event_sp);
}
}
}
}
else
{
error.SetErrorStringWithFormat("file doesn't exist: '%s'", local_exec_file_path);
}
}
return error;
}
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
Error
Process::LoadCore ()
{
Error error = DoLoadCore();
if (error.Success())
{
if (PrivateStateThreadIsValid ())
ResumePrivateStateThread ();
else
StartPrivateStateThread ();
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidAttach();
GetJITLoaders().DidAttach();
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
system_runtime->DidAttach();
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
// We successfully loaded a core file, now pretend we stopped so we can
// show all of the threads in the core file and explore the crashed
// state.
SetPrivateState (eStateStopped);
}
return error;
}
DynamicLoader *
Process::GetDynamicLoader ()
{
if (m_dyld_ap.get() == NULL)
m_dyld_ap.reset (DynamicLoader::FindPlugin(this, NULL));
return m_dyld_ap.get();
}
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
JITLoaderList &
Process::GetJITLoaders ()
{
if (!m_jit_loaders_ap)
{
m_jit_loaders_ap.reset(new JITLoaderList());
JITLoader::LoadPlugins(this, *m_jit_loaders_ap);
}
return *m_jit_loaders_ap;
}
SystemRuntime *
Process::GetSystemRuntime ()
{
if (m_system_runtime_ap.get() == NULL)
m_system_runtime_ap.reset (SystemRuntime::FindPlugin(this));
return m_system_runtime_ap.get();
}
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
Process::NextEventAction::EventActionResult
Process::AttachCompletionHandler::PerformAction (lldb::EventSP &event_sp)
{
StateType state = ProcessEventData::GetStateFromEvent (event_sp.get());
switch (state)
{
case eStateRunning:
case eStateConnected:
return eEventActionRetry;
case eStateStopped:
case eStateCrashed:
{
// During attach, prior to sending the eStateStopped event,
// lldb_private::Process subclasses must set the new process ID.
assert (m_process->GetID() != LLDB_INVALID_PROCESS_ID);
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// We don't want these events to be reported, so go set the ShouldReportStop here:
m_process->GetThreadList().SetShouldReportStop (eVoteNo);
if (m_exec_count > 0)
{
--m_exec_count;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
RequestResume();
return eEventActionRetry;
}
else
{
m_process->CompleteAttach ();
return eEventActionSuccess;
}
}
break;
default:
case eStateExited:
case eStateInvalid:
break;
}
m_exit_string.assign ("No valid Process");
return eEventActionExit;
}
Process::NextEventAction::EventActionResult
Process::AttachCompletionHandler::HandleBeingInterrupted()
{
return eEventActionSuccess;
}
const char *
Process::AttachCompletionHandler::GetExitString ()
{
return m_exit_string.c_str();
}
Error
Process::Attach (ProcessAttachInfo &attach_info)
{
m_abi_sp.reset();
m_process_input_reader.reset();
m_dyld_ap.reset();
m_jit_loaders_ap.reset();
m_system_runtime_ap.reset();
m_os_ap.reset();
lldb::pid_t attach_pid = attach_info.GetProcessID();
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
Error error;
if (attach_pid == LLDB_INVALID_PROCESS_ID)
{
char process_name[PATH_MAX];
if (attach_info.GetExecutableFile().GetPath (process_name, sizeof(process_name)))
{
const bool wait_for_launch = attach_info.GetWaitForLaunch();
if (wait_for_launch)
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
{
error = WillAttachToProcessWithName(process_name, wait_for_launch);
if (error.Success())
{
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
{
m_should_detach = true;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateAttaching, restarted);
// Now attach using these arguments.
error = DoAttachToProcessWithName (process_name, attach_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
if (error.Fail())
{
if (GetID() != LLDB_INVALID_PROCESS_ID)
{
SetID (LLDB_INVALID_PROCESS_ID);
if (error.AsCString() == NULL)
error.SetErrorString("attach failed");
SetExitStatus(-1, error.AsCString());
}
}
else
{
SetNextEventAction(new Process::AttachCompletionHandler(this, attach_info.GetResumeCount()));
StartPrivateStateThread();
}
return error;
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
}
else
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
{
ProcessInstanceInfoList process_infos;
PlatformSP platform_sp (m_target.GetPlatform ());
if (platform_sp)
{
ProcessInstanceInfoMatch match_info;
match_info.GetProcessInfo() = attach_info;
match_info.SetNameMatchType (eNameMatchEquals);
platform_sp->FindProcesses (match_info, process_infos);
const uint32_t num_matches = process_infos.GetSize();
if (num_matches == 1)
{
attach_pid = process_infos.GetProcessIDAtIndex(0);
// Fall through and attach using the above process ID
}
else
{
match_info.GetProcessInfo().GetExecutableFile().GetPath (process_name, sizeof(process_name));
if (num_matches > 1)
error.SetErrorStringWithFormat ("more than one process named %s", process_name);
else
error.SetErrorStringWithFormat ("could not find a process named %s", process_name);
}
}
else
{
error.SetErrorString ("invalid platform, can't find processes by name");
return error;
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
}
}
else
{
error.SetErrorString ("invalid process name");
}
}
if (attach_pid != LLDB_INVALID_PROCESS_ID)
{
error = WillAttachToProcessWithID(attach_pid);
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (error.Success())
{
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
{
// Now attach using these arguments.
m_should_detach = true;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateAttaching, restarted);
error = DoAttachToProcessWithID (attach_pid, attach_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
if (error.Success())
{
SetNextEventAction(new Process::AttachCompletionHandler(this, attach_info.GetResumeCount()));
StartPrivateStateThread();
}
else
{
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (GetID() != LLDB_INVALID_PROCESS_ID)
{
SetID (LLDB_INVALID_PROCESS_ID);
const char *error_string = error.AsCString();
if (error_string == NULL)
error_string = "attach failed";
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
SetExitStatus(-1, error_string);
}
}
}
}
return error;
}
void
Process::CompleteAttach ()
{
// Let the process subclass figure out at much as it can about the process
// before we go looking for a dynamic loader plug-in.
DidAttach();
// We just attached. If we have a platform, ask it for the process architecture, and if it isn't
// the same as the one we've already set, switch architectures.
PlatformSP platform_sp (m_target.GetPlatform ());
assert (platform_sp.get());
if (platform_sp)
{
const ArchSpec &target_arch = m_target.GetArchitecture();
if (target_arch.IsValid() && !platform_sp->IsCompatibleArchitecture (target_arch, false, NULL))
{
ArchSpec platform_arch;
platform_sp = platform_sp->GetPlatformForArchitecture (target_arch, &platform_arch);
if (platform_sp)
{
m_target.SetPlatform (platform_sp);
m_target.SetArchitecture(platform_arch);
}
}
else
{
ProcessInstanceInfo process_info;
platform_sp->GetProcessInfo (GetID(), process_info);
const ArchSpec &process_arch = process_info.GetArchitecture();
if (process_arch.IsValid() && !m_target.GetArchitecture().IsExactMatch(process_arch))
m_target.SetArchitecture (process_arch);
}
}
// We have completed the attach, now it is time to find the dynamic loader
// plug-in
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidAttach();
GetJITLoaders().DidAttach();
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
system_runtime->DidAttach();
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
// Figure out which one is the executable, and set that in our target:
const ModuleList &target_modules = m_target.GetImages();
Mutex::Locker modules_locker(target_modules.GetMutex());
size_t num_modules = target_modules.GetSize();
ModuleSP new_executable_module_sp;
for (size_t i = 0; i < num_modules; i++)
{
ModuleSP module_sp (target_modules.GetModuleAtIndexUnlocked (i));
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (module_sp && module_sp->IsExecutable())
{
if (m_target.GetExecutableModulePointer() != module_sp.get())
new_executable_module_sp = module_sp;
break;
}
}
if (new_executable_module_sp)
m_target.SetExecutableModule (new_executable_module_sp, false);
}
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
Error
Process::ConnectRemote (Stream *strm, const char *remote_url)
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
{
m_abi_sp.reset();
m_process_input_reader.reset();
// Find the process and its architecture. Make sure it matches the architecture
// of the current Target, and if not adjust it.
Error error (DoConnectRemote (strm, remote_url));
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
if (error.Success())
{
if (GetID() != LLDB_INVALID_PROCESS_ID)
{
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
EventSP event_sp;
StateType state = WaitForProcessStopPrivate(NULL, event_sp);
if (state == eStateStopped || state == eStateCrashed)
{
// If we attached and actually have a process on the other end, then
// this ended up being the equivalent of an attach.
CompleteAttach ();
// This delays passing the stopped event to listeners till
// CompleteAttach gets a chance to complete...
HandlePrivateEvent (event_sp);
}
}
Many improvements to the Platform base class and subclasses. The base Platform class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
if (PrivateStateThreadIsValid ())
ResumePrivateStateThread ();
else
StartPrivateStateThread ();
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
}
return error;
}
Error
Process::PrivateResume ()
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS|LIBLLDB_LOG_STEP));
if (log)
log->Printf("Process::PrivateResume() m_stop_id = %u, public state: %s private state: %s",
m_mod_id.GetStopID(),
StateAsCString(m_public_state.GetValue()),
StateAsCString(m_private_state.GetValue()));
Error error (WillResume());
// Tell the process it is about to resume before the thread list
if (error.Success())
{
// Now let the thread list know we are about to resume so it
// can let all of our threads know that they are about to be
// resumed. Threads will each be called with
// Thread::WillResume(StateType) where StateType contains the state
// that they are supposed to have when the process is resumed
// (suspended/running/stepping). Threads should also check
// their resume signal in lldb::Thread::GetResumeSignal()
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// to see if they are supposed to start back up with a signal.
if (m_thread_list.WillResume())
{
// Last thing, do the PreResumeActions.
if (!RunPreResumeActions())
{
error.SetErrorStringWithFormat ("Process::PrivateResume PreResumeActions failed, not resuming.");
}
else
{
m_mod_id.BumpResumeID();
error = DoResume();
if (error.Success())
{
DidResume();
m_thread_list.DidResume();
if (log)
log->Printf ("Process thinks the process has resumed.");
}
}
}
else
{
// Somebody wanted to run without running. So generate a continue & a stopped event,
// and let the world handle them.
if (log)
log->Printf ("Process::PrivateResume() asked to simulate a start & stop.");
SetPrivateState(eStateRunning);
SetPrivateState(eStateStopped);
}
}
else if (log)
log->Printf ("Process::PrivateResume() got an error \"%s\".", error.AsCString("<unknown error>"));
return error;
}
Error
Process::Halt (bool clear_thread_plans)
{
// Don't clear the m_clear_thread_plans_on_stop, only set it to true if
// in case it was already set and some thread plan logic calls halt on its
// own.
m_clear_thread_plans_on_stop |= clear_thread_plans;
// First make sure we aren't in the middle of handling an event, or we might restart. This is pretty weak, since
// we could just straightaway get another event. It just narrows the window...
m_currently_handling_event.WaitForValueEqualTo(false);
// Pause our private state thread so we can ensure no one else eats
// the stop event out from under us.
Listener halt_listener ("lldb.process.halt_listener");
HijackPrivateProcessEvents(&halt_listener);
EventSP event_sp;
Error error (WillHalt());
if (error.Success())
{
2010-11-18 13:57:03 +08:00
bool caused_stop = false;
// Ask the process subclass to actually halt our process
error = DoHalt(caused_stop);
if (error.Success())
{
if (m_public_state.GetValue() == eStateAttaching)
{
SetExitStatus(SIGKILL, "Cancelled async attach.");
Destroy ();
}
else
{
// If "caused_stop" is true, then DoHalt stopped the process. If
// "caused_stop" is false, the process was already stopped.
// If the DoHalt caused the process to stop, then we want to catch
// this event and set the interrupted bool to true before we pass
// this along so clients know that the process was interrupted by
// a halt command.
if (caused_stop)
2010-11-18 13:57:03 +08:00
{
// Wait for 1 second for the process to stop.
TimeValue timeout_time;
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(10);
bool got_event = halt_listener.WaitForEvent (&timeout_time, event_sp);
StateType state = ProcessEventData::GetStateFromEvent(event_sp.get());
if (!got_event || state == eStateInvalid)
2010-11-18 13:57:03 +08:00
{
// We timeout out and didn't get a stop event...
error.SetErrorStringWithFormat ("Halt timed out. State = %s", StateAsCString(GetState()));
2010-11-18 13:57:03 +08:00
}
else
{
if (StateIsStoppedState (state, false))
{
// We caused the process to interrupt itself, so mark this
// as such in the stop event so clients can tell an interrupted
// process from a natural stop
ProcessEventData::SetInterruptedInEvent (event_sp.get(), true);
}
else
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::Halt() failed to stop, state is: %s", StateAsCString(state));
error.SetErrorString ("Did not get stopped event after halt.");
}
2010-11-18 13:57:03 +08:00
}
}
DidHalt();
}
}
}
// Resume our private state thread before we post the event (if any)
RestorePrivateProcessEvents();
2010-11-18 13:57:03 +08:00
// Post any event we might have consumed. If all goes well, we will have
// stopped the process, intercepted the event and set the interrupted
// bool in the event. Post it to the private event queue and that will end up
// correctly setting the state.
if (event_sp)
m_private_state_broadcaster.BroadcastEvent(event_sp);
2010-11-18 13:57:03 +08:00
return error;
}
Error
Process::HaltForDestroyOrDetach(lldb::EventSP &exit_event_sp)
{
Error error;
if (m_public_state.GetValue() == eStateRunning)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::Destroy() About to halt.");
error = Halt();
if (error.Success())
{
// Consume the halt event.
TimeValue timeout (TimeValue::Now());
timeout.OffsetWithSeconds(1);
StateType state = WaitForProcessToStop (&timeout, &exit_event_sp);
// If the process exited while we were waiting for it to stop, put the exited event into
// the shared pointer passed in and return. Our caller doesn't need to do anything else, since
// they don't have a process anymore...
if (state == eStateExited || m_private_state.GetValue() == eStateExited)
{
if (log)
log->Printf("Process::HaltForDestroyOrDetach() Process exited while waiting to Halt.");
return error;
}
else
exit_event_sp.reset(); // It is ok to consume any non-exit stop events
if (state != eStateStopped)
{
if (log)
log->Printf("Process::HaltForDestroyOrDetach() Halt failed to stop, state is: %s", StateAsCString(state));
// If we really couldn't stop the process then we should just error out here, but if the
// lower levels just bobbled sending the event and we really are stopped, then continue on.
StateType private_state = m_private_state.GetValue();
if (private_state != eStateStopped)
{
return error;
}
}
}
else
{
if (log)
log->Printf("Process::HaltForDestroyOrDetach() Halt got error: %s", error.AsCString());
}
}
return error;
}
Error
Process::Detach (bool keep_stopped)
{
EventSP exit_event_sp;
Error error;
m_destroy_in_process = true;
error = WillDetach();
if (error.Success())
{
if (DetachRequiresHalt())
{
error = HaltForDestroyOrDetach (exit_event_sp);
if (!error.Success())
{
m_destroy_in_process = false;
return error;
}
else if (exit_event_sp)
{
// We shouldn't need to do anything else here. There's no process left to detach from...
StopPrivateStateThread();
m_destroy_in_process = false;
return error;
}
}
m_thread_list.DiscardThreadPlans();
DisableAllBreakpointSites();
error = DoDetach(keep_stopped);
if (error.Success())
{
DidDetach();
StopPrivateStateThread();
}
else
{
return error;
}
}
m_destroy_in_process = false;
// If we exited when we were waiting for a process to stop, then
// forward the event here so we don't lose the event
if (exit_event_sp)
{
// Directly broadcast our exited event because we shut down our
// private state thread above
BroadcastEvent(exit_event_sp);
}
// If we have been interrupted (to kill us) in the middle of running, we may not end up propagating
// the last events through the event system, in which case we might strand the write lock. Unlock
// it here so when we do to tear down the process we don't get an error destroying the lock.
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
return error;
}
Error
Process::Destroy ()
{
// Tell ourselves we are in the process of destroying the process, so that we don't do any unnecessary work
// that might hinder the destruction. Remember to set this back to false when we are done. That way if the attempt
// failed and the process stays around for some reason it won't be in a confused state.
m_destroy_in_process = true;
Error error (WillDestroy());
if (error.Success())
{
EventSP exit_event_sp;
if (DestroyRequiresHalt())
{
error = HaltForDestroyOrDetach(exit_event_sp);
}
if (m_public_state.GetValue() != eStateRunning)
{
// Ditch all thread plans, and remove all our breakpoints: in case we have to restart the target to
// kill it, we don't want it hitting a breakpoint...
// Only do this if we've stopped, however, since if we didn't manage to halt it above, then
// we're not going to have much luck doing this now.
m_thread_list.DiscardThreadPlans();
DisableAllBreakpointSites();
}
error = DoDestroy();
if (error.Success())
{
DidDestroy();
StopPrivateStateThread();
}
m_stdio_communication.StopReadThread();
m_stdio_communication.Disconnect();
if (m_process_input_reader)
{
m_process_input_reader->SetIsDone(true);
m_process_input_reader->Cancel();
m_process_input_reader.reset();
}
// If we exited when we were waiting for a process to stop, then
// forward the event here so we don't lose the event
if (exit_event_sp)
{
// Directly broadcast our exited event because we shut down our
// private state thread above
BroadcastEvent(exit_event_sp);
}
// If we have been interrupted (to kill us) in the middle of running, we may not end up propagating
// the last events through the event system, in which case we might strand the write lock. Unlock
// it here so when we do to tear down the process we don't get an error destroying the lock.
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
}
m_destroy_in_process = false;
return error;
}
Error
Process::Signal (int signal)
{
Error error (WillSignal());
if (error.Success())
{
error = DoSignal(signal);
if (error.Success())
DidSignal();
}
return error;
}
lldb::ByteOrder
Process::GetByteOrder () const
{
return m_target.GetArchitecture().GetByteOrder();
}
uint32_t
Process::GetAddressByteSize () const
{
return m_target.GetArchitecture().GetAddressByteSize();
}
bool
Process::ShouldBroadcastEvent (Event *event_ptr)
{
const StateType state = Process::ProcessEventData::GetStateFromEvent (event_ptr);
bool return_value = true;
Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_EVENTS | LIBLLDB_LOG_PROCESS));
switch (state)
{
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateDetached:
case eStateExited:
case eStateUnloaded:
// These events indicate changes in the state of the debugging session, always report them.
return_value = true;
break;
case eStateInvalid:
// We stopped for no apparent reason, don't report it.
return_value = false;
break;
case eStateRunning:
case eStateStepping:
// If we've started the target running, we handle the cases where we
// are already running and where there is a transition from stopped to
// running differently.
// running -> running: Automatically suppress extra running events
// stopped -> running: Report except when there is one or more no votes
// and no yes votes.
SynchronouslyNotifyStateChanged (state);
if (m_force_next_event_delivery)
return_value = true;
else
{
switch (m_last_broadcast_state)
{
case eStateRunning:
case eStateStepping:
// We always suppress multiple runnings with no PUBLIC stop in between.
return_value = false;
break;
default:
// TODO: make this work correctly. For now always report
// run if we aren't running so we don't miss any runnning
// events. If I run the lldb/test/thread/a.out file and
// break at main.cpp:58, run and hit the breakpoints on
// multiple threads, then somehow during the stepping over
// of all breakpoints no run gets reported.
// This is a transition from stop to run.
switch (m_thread_list.ShouldReportRun (event_ptr))
{
case eVoteYes:
case eVoteNoOpinion:
return_value = true;
break;
case eVoteNo:
return_value = false;
break;
}
break;
}
}
break;
case eStateStopped:
case eStateCrashed:
case eStateSuspended:
{
// We've stopped. First see if we're going to restart the target.
// If we are going to stop, then we always broadcast the event.
// If we aren't going to stop, let the thread plans decide if we're going to report this event.
// If no thread has an opinion, we don't report it.
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
RefreshStateAfterStop ();
if (ProcessEventData::GetInterruptedFromEvent (event_ptr))
{
2010-11-18 13:57:03 +08:00
if (log)
log->Printf ("Process::ShouldBroadcastEvent (%p) stopped due to an interrupt, state: %s",
event_ptr,
StateAsCString(state));
return_value = true;
}
else
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
bool was_restarted = ProcessEventData::GetRestartedFromEvent (event_ptr);
bool should_resume = false;
// It makes no sense to ask "ShouldStop" if we've already been restarted...
// Asking the thread list is also not likely to go well, since we are running again.
// So in that case just report the event.
if (!was_restarted)
should_resume = m_thread_list.ShouldStop (event_ptr) == false;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if (was_restarted || should_resume || m_resume_requested)
{
Vote stop_vote = m_thread_list.ShouldReportStop (event_ptr);
if (log)
log->Printf ("Process::ShouldBroadcastEvent: should_stop: %i state: %s was_restarted: %i stop_vote: %d.",
should_resume,
StateAsCString(state),
was_restarted,
stop_vote);
switch (stop_vote)
{
case eVoteYes:
return_value = true;
break;
case eVoteNoOpinion:
case eVoteNo:
return_value = false;
break;
}
if (!was_restarted)
{
if (log)
log->Printf ("Process::ShouldBroadcastEvent (%p) Restarting process from state: %s", event_ptr, StateAsCString(state));
ProcessEventData::SetRestartedInEvent(event_ptr, true);
PrivateResume ();
}
}
else
{
return_value = true;
SynchronouslyNotifyStateChanged (state);
}
}
}
break;
}
// Forcing the next event delivery is a one shot deal. So reset it here.
m_force_next_event_delivery = false;
// We do some coalescing of events (for instance two consecutive running events get coalesced.)
// But we only coalesce against events we actually broadcast. So we use m_last_broadcast_state
// to track that. NB - you can't use "m_public_state.GetValue()" for that purpose, as was originally done,
// because the PublicState reflects the last event pulled off the queue, and there may be several
// events stacked up on the queue unserviced. So the PublicState may not reflect the last broadcasted event
// yet. m_last_broadcast_state gets updated here.
if (return_value)
m_last_broadcast_state = state;
if (log)
log->Printf ("Process::ShouldBroadcastEvent (%p) => new state: %s, last broadcast state: %s - %s",
event_ptr,
StateAsCString(state),
StateAsCString(m_last_broadcast_state),
return_value ? "YES" : "NO");
return return_value;
}
bool
Process::StartPrivateStateThread (bool force)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EVENTS));
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
bool already_running = PrivateStateThreadIsValid ();
if (log)
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
log->Printf ("Process::%s()%s ", __FUNCTION__, already_running ? " already running" : " starting private state thread");
if (!force && already_running)
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
return true;
// Create a thread that watches our internal state and controls which
// events make it to clients (into the DCProcess event queue).
Put more smarts into the RegisterContext base class. Now the base class has a method: void RegisterContext::InvalidateIfNeeded (bool force); Each time this function is called, when "force" is false, it will only call the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if the register context's stop ID doesn't match that of the process. When the stop ID doesn't match, or "force" is true, the base class will clear its cached registers and the RegisterContext will update its stop ID to match that of the process. This helps make it easier to correctly flush the register context (possibly from multiple locations depending on when and where new registers are availabe) without inadvertently clearing the register cache when it doesn't need to be. Modified the ProcessGDBRemote plug-in to be much more efficient when it comes to: - caching the expedited registers in the stop reply packets (we were ignoring these before and it was causing us to read at least three registers every time we stopped that were already supplied in the stop reply packet). - When a thread has no stop reason, don't keep asking for the thread stopped info. Prior to this fix we would continually send a qThreadStopInfo packet over and over when any thread stop info was requested. We now note the stop ID that the stop info was requested for and avoid multiple requests. Cleaned up some of the expression code to not look for ClangExpressionVariable objects up by name since they are now shared pointers and we can just look for the exact pointer match and avoid possible errors. Fixed an bug in the ValueObject code that would cause children to not be displayed. llvm-svn: 123127
2011-01-10 05:07:35 +08:00
char thread_name[1024];
if (already_running)
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state-override(pid=%" PRIu64 ")>", GetID());
else
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state(pid=%" PRIu64 ")>", GetID());
// Create the private state thread, and start it running.
Put more smarts into the RegisterContext base class. Now the base class has a method: void RegisterContext::InvalidateIfNeeded (bool force); Each time this function is called, when "force" is false, it will only call the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if the register context's stop ID doesn't match that of the process. When the stop ID doesn't match, or "force" is true, the base class will clear its cached registers and the RegisterContext will update its stop ID to match that of the process. This helps make it easier to correctly flush the register context (possibly from multiple locations depending on when and where new registers are availabe) without inadvertently clearing the register cache when it doesn't need to be. Modified the ProcessGDBRemote plug-in to be much more efficient when it comes to: - caching the expedited registers in the stop reply packets (we were ignoring these before and it was causing us to read at least three registers every time we stopped that were already supplied in the stop reply packet). - When a thread has no stop reason, don't keep asking for the thread stopped info. Prior to this fix we would continually send a qThreadStopInfo packet over and over when any thread stop info was requested. We now note the stop ID that the stop info was requested for and avoid multiple requests. Cleaned up some of the expression code to not look for ClangExpressionVariable objects up by name since they are now shared pointers and we can just look for the exact pointer match and avoid possible errors. Fixed an bug in the ValueObject code that would cause children to not be displayed. llvm-svn: 123127
2011-01-10 05:07:35 +08:00
m_private_state_thread = Host::ThreadCreate (thread_name, Process::PrivateStateThread, this, NULL);
bool success = IS_VALID_LLDB_HOST_THREAD(m_private_state_thread);
if (success)
{
ResumePrivateStateThread();
return true;
}
else
return false;
}
void
Process::PausePrivateStateThread ()
{
ControlPrivateStateThread (eBroadcastInternalStateControlPause);
}
void
Process::ResumePrivateStateThread ()
{
ControlPrivateStateThread (eBroadcastInternalStateControlResume);
}
void
Process::StopPrivateStateThread ()
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (PrivateStateThreadIsValid ())
ControlPrivateStateThread (eBroadcastInternalStateControlStop);
else
{
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Went to stop the private state thread, but it was already invalid.");
}
}
void
Process::ControlPrivateStateThread (uint32_t signal)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
assert (signal == eBroadcastInternalStateControlStop ||
signal == eBroadcastInternalStateControlPause ||
signal == eBroadcastInternalStateControlResume);
if (log)
log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
// Signal the private state thread. First we should copy this is case the
// thread starts exiting since the private state thread will NULL this out
// when it exits
const lldb::thread_t private_state_thread = m_private_state_thread;
if (IS_VALID_LLDB_HOST_THREAD(private_state_thread))
{
TimeValue timeout_time;
bool timed_out;
m_private_state_control_broadcaster.BroadcastEvent (signal, NULL);
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(2);
if (log)
log->Printf ("Sending control event of type: %d.", signal);
m_private_state_control_wait.WaitForValueEqualTo (true, &timeout_time, &timed_out);
m_private_state_control_wait.SetValue (false, eBroadcastNever);
if (signal == eBroadcastInternalStateControlStop)
{
if (timed_out)
{
Error error;
Host::ThreadCancel (private_state_thread, &error);
if (log)
log->Printf ("Timed out responding to the control event, cancel got error: \"%s\".", error.AsCString());
}
else
{
if (log)
log->Printf ("The control event killed the private state thread without having to cancel.");
}
thread_result_t result = NULL;
Host::ThreadJoin (private_state_thread, &result, NULL);
m_private_state_thread = LLDB_INVALID_HOST_THREAD;
}
}
else
{
if (log)
log->Printf ("Private state thread already dead, no need to signal it to stop.");
}
}
void
Process::SendAsyncInterrupt ()
{
if (PrivateStateThreadIsValid())
m_private_state_broadcaster.BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
else
BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
}
void
Process::HandlePrivateEvent (EventSP &event_sp)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
m_resume_requested = false;
m_currently_handling_event.SetValue(true, eBroadcastNever);
const StateType new_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
// First check to see if anybody wants a shot at this event:
if (m_next_event_action_ap.get() != NULL)
{
NextEventAction::EventActionResult action_result = m_next_event_action_ap->PerformAction(event_sp);
if (log)
log->Printf ("Ran next event action, result was %d.", action_result);
switch (action_result)
{
case NextEventAction::eEventActionSuccess:
SetNextEventAction(NULL);
break;
case NextEventAction::eEventActionRetry:
break;
case NextEventAction::eEventActionExit:
// Handle Exiting Here. If we already got an exited event,
// we should just propagate it. Otherwise, swallow this event,
// and set our state to exit so the next event will kill us.
if (new_state != eStateExited)
{
// FIXME: should cons up an exited event, and discard this one.
SetExitStatus(0, m_next_event_action_ap->GetExitString());
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
m_currently_handling_event.SetValue(false, eBroadcastAlways);
SetNextEventAction(NULL);
return;
}
SetNextEventAction(NULL);
break;
}
}
// See if we should broadcast this state to external clients?
const bool should_broadcast = ShouldBroadcastEvent (event_sp.get());
if (should_broadcast)
{
const bool is_hijacked = IsHijackedForEvent(eBroadcastBitStateChanged);
if (log)
{
log->Printf ("Process::%s (pid = %" PRIu64 ") broadcasting new state %s (old state %s) to %s",
__FUNCTION__,
GetID(),
StateAsCString(new_state),
StateAsCString (GetState ()),
is_hijacked ? "hijacked" : "public");
}
Process::ProcessEventData::SetUpdateStateOnRemoval(event_sp.get());
if (StateIsRunningState (new_state))
{
// Only push the input handler if we aren't fowarding events,
// as this means the curses GUI is in use...
if (!GetTarget().GetDebugger().IsForwardingEvents())
PushProcessIOHandler ();
}
else if (StateIsStoppedState(new_state, false))
{
if (!Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
{
// If the lldb_private::Debugger is handling the events, we don't
// want to pop the process IOHandler here, we want to do it when
// we receive the stopped event so we can carefully control when
// the process IOHandler is popped because when we stop we want to
// display some text stating how and why we stopped, then maybe some
// process/thread/frame info, and then we want the "(lldb) " prompt
// to show up. If we pop the process IOHandler here, then we will
// cause the command interpreter to become the top IOHandler after
// the process pops off and it will update its prompt right away...
// See the Debugger.cpp file where it calls the function as
// "process_sp->PopProcessIOHandler()" to see where I am talking about.
// Otherwise we end up getting overlapping "(lldb) " prompts and
// garbled output.
//
// If we aren't handling the events in the debugger (which is indicated
// by "m_target.GetDebugger().IsHandlingEvents()" returning false) or we
// are hijacked, then we always pop the process IO handler manually.
// Hijacking happens when the internal process state thread is running
// thread plans, or when commands want to run in synchronous mode
// and they call "process->WaitForProcessToStop()". An example of something
// that will hijack the events is a simple expression:
//
// (lldb) expr (int)puts("hello")
//
// This will cause the internal process state thread to resume and halt
// the process (and _it_ will hijack the eBroadcastBitStateChanged
// events) and we do need the IO handler to be pushed and popped
// correctly.
if (is_hijacked || m_target.GetDebugger().IsHandlingEvents() == false)
PopProcessIOHandler ();
}
}
BroadcastEvent (event_sp);
}
else
{
if (log)
{
log->Printf ("Process::%s (pid = %" PRIu64 ") suppressing state %s (old state %s): should_broadcast == false",
__FUNCTION__,
GetID(),
StateAsCString(new_state),
StateAsCString (GetState ()));
}
}
m_currently_handling_event.SetValue(false, eBroadcastAlways);
}
thread_result_t
Process::PrivateStateThread (void *arg)
{
Process *proc = static_cast<Process*> (arg);
thread_result_t result = proc->RunPrivateStateThread();
return result;
}
thread_result_t
Process::RunPrivateStateThread ()
{
bool control_only = true;
m_private_state_control_wait.SetValue (false, eBroadcastNever);
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread starting...", __FUNCTION__, this, GetID());
bool exit_now = false;
while (!exit_now)
{
EventSP event_sp;
WaitForEventsPrivate (NULL, event_sp, control_only);
if (event_sp->BroadcasterIs(&m_private_state_control_broadcaster))
{
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") got a control event: %d", __FUNCTION__, this, GetID(), event_sp->GetType());
switch (event_sp->GetType())
{
case eBroadcastInternalStateControlStop:
exit_now = true;
break; // doing any internal state managment below
case eBroadcastInternalStateControlPause:
control_only = true;
break;
case eBroadcastInternalStateControlResume:
control_only = false;
break;
}
m_private_state_control_wait.SetValue (true, eBroadcastAlways);
continue;
}
else if (event_sp->GetType() == eBroadcastBitInterrupt)
{
if (m_public_state.GetValue() == eStateAttaching)
{
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt while attaching - forwarding interrupt.", __FUNCTION__, this, GetID());
BroadcastEvent (eBroadcastBitInterrupt, NULL);
}
else
{
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt - Halting.", __FUNCTION__, this, GetID());
Halt();
}
continue;
}
const StateType internal_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (internal_state != eStateInvalid)
{
if (m_clear_thread_plans_on_stop &&
StateIsStoppedState(internal_state, true))
{
m_clear_thread_plans_on_stop = false;
m_thread_list.DiscardThreadPlans();
}
HandlePrivateEvent (event_sp);
}
if (internal_state == eStateInvalid ||
internal_state == eStateExited ||
internal_state == eStateDetached )
{
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") about to exit with internal state %s...", __FUNCTION__, this, GetID(), StateAsCString(internal_state));
break;
}
}
// Verify log is still enabled before attempting to write to it...
if (log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread exiting...", __FUNCTION__, this, GetID());
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
m_private_state_control_wait.SetValue (true, eBroadcastAlways);
m_private_state_thread = LLDB_INVALID_HOST_THREAD;
return NULL;
}
//------------------------------------------------------------------
// Process Event Data
//------------------------------------------------------------------
Process::ProcessEventData::ProcessEventData () :
EventData (),
m_process_sp (),
m_state (eStateInvalid),
m_restarted (false),
m_update_state (0),
m_interrupted (false)
{
}
Process::ProcessEventData::ProcessEventData (const ProcessSP &process_sp, StateType state) :
EventData (),
m_process_sp (process_sp),
m_state (state),
m_restarted (false),
m_update_state (0),
m_interrupted (false)
{
}
Process::ProcessEventData::~ProcessEventData()
{
}
const ConstString &
Process::ProcessEventData::GetFlavorString ()
{
static ConstString g_flavor ("Process::ProcessEventData");
return g_flavor;
}
const ConstString &
Process::ProcessEventData::GetFlavor () const
{
return ProcessEventData::GetFlavorString ();
}
void
Process::ProcessEventData::DoOnRemoval (Event *event_ptr)
{
// This function gets called twice for each event, once when the event gets pulled
// off of the private process event queue, and then any number of times, first when it gets pulled off of
// the public event queue, then other times when we're pretending that this is where we stopped at the
// end of expression evaluation. m_update_state is used to distinguish these
// three cases; it is 0 when we're just pulling it off for private handling,
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// and > 1 for expression evaluation, and we don't want to do the breakpoint command handling then.
if (m_update_state != 1)
return;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
m_process_sp->SetPublicState (m_state, Process::ProcessEventData::GetRestartedFromEvent(event_ptr));
// If we're stopped and haven't restarted, then do the breakpoint commands here:
if (m_state == eStateStopped && ! m_restarted)
{
ThreadList &curr_thread_list = m_process_sp->GetThreadList();
uint32_t num_threads = curr_thread_list.GetSize();
uint32_t idx;
Abtracted the old "lldb_private::Thread::StopInfo" into an abtract class. This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo" that can completely describe any stop reason. It also provides a framework for doing intelligent things with the stop info at important times in the lifetime of the inferior. Examples include the signal stop info in StopInfoUnixSignal. It will check with the process to see that the current action is for the signal. These actions include wether to stop for the signal, wether the notify that the signal was hit, and wether to pass the signal along to the inferior process. The StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and this allows the stop info to determine if it should stop at the signal or continue the process. StopInfo subclasses must override the following functions: virtual lldb::StopReason GetStopReason () const = 0; virtual const char * GetDescription () = 0; StopInfo subclasses can override the following functions: // If the subclass returns "false", the inferior will resume. The default // version of this function returns "true" which means the default stop // info will stop the process. The breakpoint subclass will check if // the breakpoint wants us to stop by calling any installed callback on // the breakpoint, and also checking if the breakpoint is for the current // thread. Signals will check if they should stop based off of the // UnixSignal settings in the process. virtual bool ShouldStop (Event *event_ptr); // Sublasses can state if they want to notify the debugger when "ShouldStop" // returns false. This would be handy for breakpoints where you want to // log information and continue and is also used by the signal stop info // to notify that a signal was received (after it checks with the process // signal settings). virtual bool ShouldNotify (Event *event_ptr) { return false; } // Allow subclasses to do something intelligent right before we resume. // The signal class will figure out if the signal should be propagated // to the inferior process and pass that along to the debugger plug-ins. virtual void WillResume (lldb::StateType resume_state) { // By default, don't do anything } The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility folder and now doesn't polute the lldb_private::Thread class with platform specific code. llvm-svn: 110184
2010-08-04 09:40:35 +08:00
// The actions might change one of the thread's stop_info's opinions about whether we should
// stop the process, so we need to query that as we go.
// One other complication here, is that we try to catch any case where the target has run (except for expressions)
// and immediately exit, but if we get that wrong (which is possible) then the thread list might have changed, and
// that would cause our iteration here to crash. We could make a copy of the thread list, but we'd really like
// to also know if it has changed at all, so we make up a vector of the thread ID's and check what we get back
// against this list & bag out if anything differs.
std::vector<uint32_t> thread_index_array(num_threads);
for (idx = 0; idx < num_threads; ++idx)
thread_index_array[idx] = curr_thread_list.GetThreadAtIndex(idx)->GetIndexID();
// Use this to track whether we should continue from here. We will only continue the target running if
// no thread says we should stop. Of course if some thread's PerformAction actually sets the target running,
// then it doesn't matter what the other threads say...
bool still_should_stop = false;
// Sometimes - for instance if we have a bug in the stub we are talking to, we stop but no thread has a
// valid stop reason. In that case we should just stop, because we have no way of telling what the right
// thing to do is, and it's better to let the user decide than continue behind their backs.
bool does_anybody_have_an_opinion = false;
for (idx = 0; idx < num_threads; ++idx)
{
curr_thread_list = m_process_sp->GetThreadList();
if (curr_thread_list.GetSize() != num_threads)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Number of threads changed from %u to %u while processing event.", num_threads, curr_thread_list.GetSize());
break;
}
lldb::ThreadSP thread_sp = curr_thread_list.GetThreadAtIndex(idx);
if (thread_sp->GetIndexID() != thread_index_array[idx])
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("The thread at position %u changed from %u to %u while processing event.",
idx,
thread_index_array[idx],
thread_sp->GetIndexID());
break;
}
StopInfoSP stop_info_sp = thread_sp->GetStopInfo ();
if (stop_info_sp && stop_info_sp->IsValid())
{
does_anybody_have_an_opinion = true;
bool this_thread_wants_to_stop;
if (stop_info_sp->GetOverrideShouldStop())
{
this_thread_wants_to_stop = stop_info_sp->GetOverriddenShouldStopValue();
}
else
{
stop_info_sp->PerformAction(event_ptr);
// The stop action might restart the target. If it does, then we want to mark that in the
// event so that whoever is receiving it will know to wait for the running event and reflect
// that state appropriately.
// We also need to stop processing actions, since they aren't expecting the target to be running.
// FIXME: we might have run.
if (stop_info_sp->HasTargetRunSinceMe())
{
SetRestarted (true);
break;
}
this_thread_wants_to_stop = stop_info_sp->ShouldStop(event_ptr);
}
if (still_should_stop == false)
still_should_stop = this_thread_wants_to_stop;
}
}
if (!GetRestarted())
{
if (!still_should_stop && does_anybody_have_an_opinion)
{
// We've been asked to continue, so do that here.
SetRestarted(true);
// Use the public resume method here, since this is just
// extending a public resume.
m_process_sp->PrivateResume();
}
else
{
// If we didn't restart, run the Stop Hooks here:
// They might also restart the target, so watch for that.
m_process_sp->GetTarget().RunStopHooks();
if (m_process_sp->GetPrivateState() == eStateRunning)
SetRestarted(true);
}
}
}
}
void
Process::ProcessEventData::Dump (Stream *s) const
{
if (m_process_sp)
s->Printf(" process = %p (pid = %" PRIu64 "), ", m_process_sp.get(), m_process_sp->GetID());
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
s->Printf("state = %s", StateAsCString(GetState()));
}
const Process::ProcessEventData *
Process::ProcessEventData::GetEventDataFromEvent (const Event *event_ptr)
{
if (event_ptr)
{
const EventData *event_data = event_ptr->GetData();
if (event_data && event_data->GetFlavor() == ProcessEventData::GetFlavorString())
return static_cast <const ProcessEventData *> (event_ptr->GetData());
}
return NULL;
}
ProcessSP
Process::ProcessEventData::GetProcessFromEvent (const Event *event_ptr)
{
ProcessSP process_sp;
const ProcessEventData *data = GetEventDataFromEvent (event_ptr);
if (data)
process_sp = data->GetProcessSP();
return process_sp;
}
StateType
Process::ProcessEventData::GetStateFromEvent (const Event *event_ptr)
{
const ProcessEventData *data = GetEventDataFromEvent (event_ptr);
if (data == NULL)
return eStateInvalid;
else
return data->GetState();
}
bool
Process::ProcessEventData::GetRestartedFromEvent (const Event *event_ptr)
{
const ProcessEventData *data = GetEventDataFromEvent (event_ptr);
if (data == NULL)
return false;
else
return data->GetRestarted();
}
void
Process::ProcessEventData::SetRestartedInEvent (Event *event_ptr, bool new_value)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data != NULL)
data->SetRestarted(new_value);
}
size_t
Process::ProcessEventData::GetNumRestartedReasons(const Event *event_ptr)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data != NULL)
return data->GetNumRestartedReasons();
else
return 0;
}
const char *
Process::ProcessEventData::GetRestartedReasonAtIndex(const Event *event_ptr, size_t idx)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data != NULL)
return data->GetRestartedReasonAtIndex(idx);
else
return NULL;
}
void
Process::ProcessEventData::AddRestartedReason (Event *event_ptr, const char *reason)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data != NULL)
data->AddRestartedReason(reason);
}
bool
Process::ProcessEventData::GetInterruptedFromEvent (const Event *event_ptr)
{
const ProcessEventData *data = GetEventDataFromEvent (event_ptr);
if (data == NULL)
return false;
else
return data->GetInterrupted ();
}
void
Process::ProcessEventData::SetInterruptedInEvent (Event *event_ptr, bool new_value)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data != NULL)
data->SetInterrupted(new_value);
}
bool
Process::ProcessEventData::SetUpdateStateOnRemoval (Event *event_ptr)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data)
{
data->SetUpdateStateOnRemoval();
return true;
}
return false;
}
lldb::TargetSP
Process::CalculateTarget ()
{
return m_target.shared_from_this();
}
void
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Process::CalculateExecutionContext (ExecutionContext &exe_ctx)
{
exe_ctx.SetTargetPtr (&m_target);
exe_ctx.SetProcessPtr (this);
exe_ctx.SetThreadPtr(NULL);
exe_ctx.SetFramePtr (NULL);
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
//uint32_t
//Process::ListProcessesMatchingName (const char *name, StringList &matches, std::vector<lldb::pid_t> &pids)
//{
// return 0;
//}
//
//ArchSpec
//Process::GetArchSpecForExistingProcess (lldb::pid_t pid)
//{
// return Host::GetArchSpecForExistingProcess (pid);
//}
//
//ArchSpec
//Process::GetArchSpecForExistingProcess (const char *process_name)
//{
// return Host::GetArchSpecForExistingProcess (process_name);
//}
//
void
Process::AppendSTDOUT (const char * s, size_t len)
{
2010-11-18 13:57:03 +08:00
Mutex::Locker locker (m_stdio_communication_mutex);
m_stdout_data.append (s, len);
BroadcastEventIfUnique (eBroadcastBitSTDOUT, new ProcessEventData (shared_from_this(), GetState()));
}
void
Process::AppendSTDERR (const char * s, size_t len)
{
Mutex::Locker locker (m_stdio_communication_mutex);
m_stderr_data.append (s, len);
BroadcastEventIfUnique (eBroadcastBitSTDERR, new ProcessEventData (shared_from_this(), GetState()));
}
void
Process::BroadcastAsyncProfileData(const std::string &one_profile_data)
{
Mutex::Locker locker (m_profile_data_comm_mutex);
m_profile_data.push_back(one_profile_data);
BroadcastEventIfUnique (eBroadcastBitProfileData, new ProcessEventData (shared_from_this(), GetState()));
}
size_t
Process::GetAsyncProfileData (char *buf, size_t buf_size, Error &error)
{
Mutex::Locker locker(m_profile_data_comm_mutex);
if (m_profile_data.empty())
return 0;
std::string &one_profile_data = m_profile_data.front();
size_t bytes_available = one_profile_data.size();
if (bytes_available > 0)
{
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::GetProfileData (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
if (bytes_available > buf_size)
{
memcpy(buf, one_profile_data.c_str(), buf_size);
one_profile_data.erase(0, buf_size);
bytes_available = buf_size;
}
else
{
memcpy(buf, one_profile_data.c_str(), bytes_available);
m_profile_data.erase(m_profile_data.begin());
}
}
return bytes_available;
}
//------------------------------------------------------------------
// Process STDIO
//------------------------------------------------------------------
size_t
Process::GetSTDOUT (char *buf, size_t buf_size, Error &error)
{
Mutex::Locker locker(m_stdio_communication_mutex);
size_t bytes_available = m_stdout_data.size();
if (bytes_available > 0)
{
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::GetSTDOUT (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
if (bytes_available > buf_size)
{
memcpy(buf, m_stdout_data.c_str(), buf_size);
m_stdout_data.erase(0, buf_size);
bytes_available = buf_size;
}
else
{
memcpy(buf, m_stdout_data.c_str(), bytes_available);
m_stdout_data.clear();
}
}
return bytes_available;
}
size_t
Process::GetSTDERR (char *buf, size_t buf_size, Error &error)
{
Mutex::Locker locker(m_stdio_communication_mutex);
size_t bytes_available = m_stderr_data.size();
if (bytes_available > 0)
{
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::GetSTDERR (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
if (bytes_available > buf_size)
{
memcpy(buf, m_stderr_data.c_str(), buf_size);
m_stderr_data.erase(0, buf_size);
bytes_available = buf_size;
}
else
{
memcpy(buf, m_stderr_data.c_str(), bytes_available);
m_stderr_data.clear();
}
}
return bytes_available;
}
void
Process::STDIOReadThreadBytesReceived (void *baton, const void *src, size_t src_len)
{
Process *process = (Process *) baton;
process->AppendSTDOUT (static_cast<const char *>(src), src_len);
}
class IOHandlerProcessSTDIO :
public IOHandler
{
public:
IOHandlerProcessSTDIO (Process *process,
int write_fd) :
IOHandler(process->GetTarget().GetDebugger()),
m_process (process),
m_read_file (),
m_write_file (write_fd, false),
m_pipe_read(),
m_pipe_write()
{
m_read_file.SetDescriptor(GetInputFD(), false);
}
virtual
~IOHandlerProcessSTDIO ()
{
}
bool
OpenPipes ()
{
if (m_pipe_read.IsValid() && m_pipe_write.IsValid())
return true;
int fds[2];
#ifdef _WIN32
// pipe is not supported on windows so default to a fail condition
int err = 1;
#else
int err = pipe(fds);
#endif
if (err == 0)
{
m_pipe_read.SetDescriptor(fds[0], true);
m_pipe_write.SetDescriptor(fds[1], true);
return true;
}
return false;
}
void
ClosePipes()
{
m_pipe_read.Close();
m_pipe_write.Close();
}
// Each IOHandler gets to run until it is done. It should read data
// from the "in" and place output into "out" and "err and return
// when done.
virtual void
Run ()
{
if (m_read_file.IsValid() && m_write_file.IsValid())
{
SetIsDone(false);
if (OpenPipes())
{
const int read_fd = m_read_file.GetDescriptor();
const int pipe_read_fd = m_pipe_read.GetDescriptor();
TerminalState terminal_state;
terminal_state.Save (read_fd, false);
Terminal terminal(read_fd);
terminal.SetCanonical(false);
terminal.SetEcho(false);
// FD_ZERO, FD_SET are not supported on windows
#ifndef _WIN32
while (!GetIsDone())
{
fd_set read_fdset;
FD_ZERO (&read_fdset);
FD_SET (read_fd, &read_fdset);
FD_SET (pipe_read_fd, &read_fdset);
const int nfds = std::max<int>(read_fd, pipe_read_fd) + 1;
int num_set_fds = select (nfds, &read_fdset, NULL, NULL, NULL);
if (num_set_fds < 0)
{
const int select_errno = errno;
if (select_errno != EINTR)
SetIsDone(true);
}
else if (num_set_fds > 0)
{
char ch = 0;
size_t n;
if (FD_ISSET (read_fd, &read_fdset))
{
n = 1;
if (m_read_file.Read(&ch, n).Success() && n == 1)
{
if (m_write_file.Write(&ch, n).Fail() || n != 1)
SetIsDone(true);
}
else
SetIsDone(true);
}
if (FD_ISSET (pipe_read_fd, &read_fdset))
{
// Consume the interrupt byte
n = 1;
m_pipe_read.Read (&ch, n);
switch (ch)
{
case 'q':
SetIsDone(true);
break;
case 'i':
if (StateIsRunningState(m_process->GetState()))
m_process->Halt();
break;
}
}
}
}
#endif
terminal_state.Restore();
}
else
SetIsDone(true);
}
else
SetIsDone(true);
}
// Hide any characters that have been displayed so far so async
// output can be displayed. Refresh() will be called after the
// output has been displayed.
virtual void
Hide ()
{
}
// Called when the async output has been received in order to update
// the input reader (refresh the prompt and redisplay any current
// line(s) that are being edited
virtual void
Refresh ()
{
}
virtual void
Cancel ()
{
size_t n = 1;
char ch = 'q'; // Send 'q' for quit
m_pipe_write.Write (&ch, n);
}
virtual void
Interrupt ()
{
#ifdef _MSC_VER
// Windows doesn't support pipes, so we will send an async interrupt
// event to stop the process
if (StateIsRunningState(m_process->GetState()))
Reapply r184270 by Jim Ingham to avoid abort on FreeBSD Don't actually Halt in the Interrupt handler for the Process, just send an AsyncInterrupt. That's actually not async-signal-clean, but it is a lot safer than Halt... The underlying problem is actually a nested pthread_cond_wait from the signal handler. Note frames 4, 13, 18 in the backtrace of the aborting path below. frame #1: 0x000000080715fff9 libc.so.7`abort + 73 at abort.c:65 frame #2: 0x0000000805d20fda libthr.so.3`_thread_exit(fname=<unavailable>, lineno=<unavailable>, msg=<unavailable>) + 58 at thr_exit.c:182 frame #3: 0x0000000805d1fdc8 libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 936 at thr_cond.c:223 frame #4: 0x0000000805d1fd5b libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 827 at thr_cond.c:311 frame #5: 0x00000008013450b5 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 117 frame #6: 0x00000008013411e8 liblldb.so.3.5`lldb_private::Predicate<bool>::WaitForValueEqualTo(bool, lldb_private::TimeValue const*, bool*) + 200 frame #7: 0x00000008013eb34c liblldb.so.3.5`lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::__1::shared_ptr<lldb_private::Event>&) + 876 frame #8: 0x00000008013eb751 liblldb.so.3.5`lldb_private::Listener::WaitForEvent(lldb_private::TimeValue const*, std::__1::shared_ptr<lldb_private::Event>&) + 81 frame #9: 0x00000008017c5bcf liblldb.so.3.5`lldb_private::Process::Halt(bool) + 783 frame #10: 0x00000008017def3a liblldb.so.3.5`IOHandlerProcessSTDIO::Interrupt() + 74 frame #11: 0x00000008013823d3 liblldb.so.3.5`lldb_private::Debugger::DispatchInputInterrupt() + 115 frame #12: 0x00000008011d69c5 liblldb.so.3.5`lldb::SBDebugger::DispatchInputInterrupt() + 69 frame #13: 0x000000000040b254 lldb`sigint_handler(int) + 68 frame #14: 0x0000000805d1b3da libthr.so.3`handle_signal(actp=<unavailable>, sig=<unavailable>, info=<unavailable>, ucp=<unavailable>) + 234 at thr_sig.c:240 frame #15: 0x0000000805d1afc2 libthr.so.3`thr_sighandler(sig=<unavailable>, info=<unavailable>, _ucp=<unavailable>) + 306 at thr_sig.c:183 frame #16: 0x00007ffffffff003 frame #17: 0x0000000805d1fc7e libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=1) + 239 at thr_cond.c:255 frame #18: 0x0000000805d1fb8f libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) + 367 at thr_cond.c:311 frame #19: 0x00000008013450d2 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 146 llvm-svn: 202154
2014-02-25 22:20:14 +08:00
m_process->SendAsyncInterrupt();
#else
// Do only things that are safe to do in an interrupt context (like in
// a SIGINT handler), like write 1 byte to a file descriptor. This will
// interrupt the IOHandlerProcessSTDIO::Run() and we can look at the byte
// that was written to the pipe and then call m_process->Halt() from a
// much safer location in code.
size_t n = 1;
char ch = 'i'; // Send 'i' for interrupt
m_pipe_write.Write (&ch, n);
#endif
}
virtual void
GotEOF()
{
}
protected:
Process *m_process;
File m_read_file; // Read from this file (usually actual STDIN for LLDB
File m_write_file; // Write to this file (usually the master pty for getting io to debuggee)
File m_pipe_read;
File m_pipe_write;
};
void
Process::SetSTDIOFileDescriptor (int fd)
{
// First set up the Read Thread for reading/handling process I/O
std::unique_ptr<ConnectionFileDescriptor> conn_ap (new ConnectionFileDescriptor (fd, true));
if (conn_ap.get())
{
m_stdio_communication.SetConnection (conn_ap.release());
if (m_stdio_communication.IsConnected())
{
m_stdio_communication.SetReadThreadBytesReceivedCallback (STDIOReadThreadBytesReceived, this);
m_stdio_communication.StartReadThread();
// Now read thread is set up, set up input reader.
if (!m_process_input_reader.get())
m_process_input_reader.reset (new IOHandlerProcessSTDIO (this, fd));
}
}
}
bool
Process::ProcessIOHandlerIsActive ()
{
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
return m_target.GetDebugger().IsTopIOHandler (io_handler_sp);
return false;
}
bool
Process::PushProcessIOHandler ()
{
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
{
io_handler_sp->SetIsDone(false);
m_target.GetDebugger().PushIOHandler (io_handler_sp);
return true;
}
return false;
}
bool
Process::PopProcessIOHandler ()
{
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
return m_target.GetDebugger().PopIOHandler (io_handler_sp);
return false;
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
// The process needs to know about installed plug-ins
void
Process::SettingsInitialize ()
{
Thread::SettingsInitialize ();
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
void
Process::SettingsTerminate ()
{
Thread::SettingsTerminate ();
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
ExecutionResults
Process::RunThreadPlan (ExecutionContext &exe_ctx,
lldb::ThreadPlanSP &thread_plan_sp,
const EvaluateExpressionOptions &options,
Stream &errors)
{
ExecutionResults return_value = eExecutionSetupError;
if (thread_plan_sp.get() == NULL)
{
errors.Printf("RunThreadPlan called with empty thread plan.");
return eExecutionSetupError;
}
if (!thread_plan_sp->ValidatePlan(NULL))
{
errors.Printf ("RunThreadPlan called with an invalid thread plan.");
return eExecutionSetupError;
}
if (exe_ctx.GetProcessPtr() != this)
{
errors.Printf("RunThreadPlan called on wrong process.");
return eExecutionSetupError;
}
Thread *thread = exe_ctx.GetThreadPtr();
if (thread == NULL)
{
errors.Printf("RunThreadPlan called with invalid thread.");
return eExecutionSetupError;
}
// We rely on the thread plan we are running returning "PlanCompleted" if when it successfully completes.
// For that to be true the plan can't be private - since private plans suppress themselves in the
// GetCompletedPlan call.
bool orig_plan_private = thread_plan_sp->GetPrivate();
thread_plan_sp->SetPrivate(false);
if (m_private_state.GetValue() != eStateStopped)
{
errors.Printf ("RunThreadPlan called while the private state was not stopped.");
return eExecutionSetupError;
}
// Save the thread & frame from the exe_ctx for restoration after we run
const uint32_t thread_idx_id = thread->GetIndexID();
StackFrameSP selected_frame_sp = thread->GetSelectedFrame();
if (!selected_frame_sp)
{
thread->SetSelectedFrame(0);
selected_frame_sp = thread->GetSelectedFrame();
if (!selected_frame_sp)
{
errors.Printf("RunThreadPlan called without a selected frame on thread %d", thread_idx_id);
return eExecutionSetupError;
}
}
StackID ctx_frame_id = selected_frame_sp->GetStackID();
// N.B. Running the target may unset the currently selected thread and frame. We don't want to do that either,
// so we should arrange to reset them as well.
lldb::ThreadSP selected_thread_sp = GetThreadList().GetSelectedThread();
uint32_t selected_tid;
StackID selected_stack_id;
if (selected_thread_sp)
{
selected_tid = selected_thread_sp->GetIndexID();
selected_stack_id = selected_thread_sp->GetSelectedFrame()->GetStackID();
}
else
{
selected_tid = LLDB_INVALID_THREAD_ID;
}
lldb::thread_t backup_private_state_thread = LLDB_INVALID_HOST_THREAD;
lldb::StateType old_state;
lldb::ThreadPlanSP stopper_base_plan_sp;
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
if (Host::GetCurrentThread() == m_private_state_thread)
{
// Yikes, we are running on the private state thread! So we can't wait for public events on this thread, since
// we are the thread that is generating public events.
// The simplest thing to do is to spin up a temporary thread to handle private state thread events while
// we are fielding public events here.
if (log)
log->Printf ("Running thread plan on private state thread, spinning up another state thread to handle the events.");
backup_private_state_thread = m_private_state_thread;
// One other bit of business: we want to run just this thread plan and anything it pushes, and then stop,
// returning control here.
// But in the normal course of things, the plan above us on the stack would be given a shot at the stop
// event before deciding to stop, and we don't want that. So we insert a "stopper" base plan on the stack
// before the plan we want to run. Since base plans always stop and return control to the user, that will
// do just what we want.
stopper_base_plan_sp.reset(new ThreadPlanBase (*thread));
thread->QueueThreadPlan (stopper_base_plan_sp, false);
// Have to make sure our public state is stopped, since otherwise the reporting logic below doesn't work correctly.
old_state = m_public_state.GetValue();
m_public_state.SetValueNoLock(eStateStopped);
// Now spin up the private state thread:
StartPrivateStateThread(true);
}
thread->QueueThreadPlan(thread_plan_sp, false); // This used to pass "true" does that make sense?
if (options.GetDebug())
{
// In this case, we aren't actually going to run, we just want to stop right away.
// Flush this thread so we will refetch the stacks and show the correct backtrace.
// FIXME: To make this prettier we should invent some stop reason for this, but that
// is only cosmetic, and this functionality is only of use to lldb developers who can
// live with not pretty...
thread->Flush();
return eExecutionStoppedForDebug;
}
Listener listener("lldb.process.listener.run-thread-plan");
lldb::EventSP event_to_broadcast_sp;
{
// This process event hijacker Hijacks the Public events and its destructor makes sure that the process events get
// restored on exit to the function.
//
// If the event needs to propagate beyond the hijacker (e.g., the process exits during execution), then the event
// is put into event_to_broadcast_sp for rebroadcasting.
ProcessEventHijacker run_thread_plan_hijacker (*this, &listener);
if (log)
{
StreamString s;
thread_plan_sp->GetDescription(&s, lldb::eDescriptionLevelVerbose);
log->Printf ("Process::RunThreadPlan(): Resuming thread %u - 0x%4.4" PRIx64 " to run thread plan \"%s\".",
thread->GetIndexID(),
thread->GetID(),
s.GetData());
}
bool got_event;
lldb::EventSP event_sp;
lldb::StateType stop_state = lldb::eStateInvalid;
TimeValue* timeout_ptr = NULL;
TimeValue real_timeout;
bool before_first_timeout = true; // This is set to false the first time that we have to halt the target.
bool do_resume = true;
bool handle_running_event = true;
const uint64_t default_one_thread_timeout_usec = 250000;
// This is just for accounting:
uint32_t num_resumes = 0;
TimeValue one_thread_timeout = TimeValue::Now();
TimeValue final_timeout = one_thread_timeout;
uint32_t timeout_usec = options.GetTimeoutUsec();
if (!options.GetStopOthers())
{
before_first_timeout = false;
final_timeout.OffsetWithMicroSeconds(timeout_usec);
}
else if (options.GetTryAllThreads())
{
uint64_t option_one_thread_timeout = options.GetOneThreadTimeoutUsec();
// If the overall wait is forever, then we only need to set the one thread timeout:
if (timeout_usec == 0)
{
if (option_one_thread_timeout != 0)
one_thread_timeout.OffsetWithMicroSeconds(option_one_thread_timeout);
else
one_thread_timeout.OffsetWithMicroSeconds(default_one_thread_timeout_usec);
}
else
{
// Otherwise, if the one thread timeout is set, make sure it isn't longer than the overall timeout,
// and use it, otherwise use half the total timeout, bounded by the default_one_thread_timeout_usec.
uint64_t computed_one_thread_timeout;
if (option_one_thread_timeout != 0)
{
if (timeout_usec < option_one_thread_timeout)
{
errors.Printf("RunThreadPlan called without one thread timeout greater than total timeout");
return eExecutionSetupError;
}
computed_one_thread_timeout = option_one_thread_timeout;
}
else
{
computed_one_thread_timeout = timeout_usec / 2;
if (computed_one_thread_timeout > default_one_thread_timeout_usec)
computed_one_thread_timeout = default_one_thread_timeout_usec;
}
one_thread_timeout.OffsetWithMicroSeconds(computed_one_thread_timeout);
}
final_timeout.OffsetWithMicroSeconds (timeout_usec);
}
else
{
if (timeout_usec != 0)
final_timeout.OffsetWithMicroSeconds(timeout_usec);
}
// This isn't going to work if there are unfetched events on the queue.
// Are there cases where we might want to run the remaining events here, and then try to
// call the function? That's probably being too tricky for our own good.
Event *other_events = listener.PeekAtNextEvent();
if (other_events != NULL)
{
errors.Printf("Calling RunThreadPlan with pending events on the queue.");
return eExecutionSetupError;
}
// We also need to make sure that the next event is delivered. We might be calling a function as part of
// a thread plan, in which case the last delivered event could be the running event, and we don't want
// event coalescing to cause us to lose OUR running event...
ForceNextEventDelivery();
// This while loop must exit out the bottom, there's cleanup that we need to do when we are done.
// So don't call return anywhere within it.
while (1)
{
// We usually want to resume the process if we get to the top of the loop.
// The only exception is if we get two running events with no intervening
// stop, which can happen, we will just wait for then next stop event.
if (log)
log->Printf ("Top of while loop: do_resume: %i handle_running_event: %i before_first_timeout: %i.",
do_resume,
handle_running_event,
before_first_timeout);
if (do_resume || handle_running_event)
{
// Do the initial resume and wait for the running event before going further.
if (do_resume)
{
num_resumes++;
Error resume_error = PrivateResume ();
if (!resume_error.Success())
{
errors.Printf("Error resuming inferior the %d time: \"%s\".\n",
num_resumes,
resume_error.AsCString());
return_value = eExecutionSetupError;
break;
}
}
TimeValue resume_timeout = TimeValue::Now();
resume_timeout.OffsetWithMicroSeconds(500000);
got_event = listener.WaitForEvent(&resume_timeout, event_sp);
if (!got_event)
{
if (log)
log->Printf ("Process::RunThreadPlan(): didn't get any event after resume %d, exiting.",
num_resumes);
errors.Printf("Didn't get any event after resume %d, exiting.", num_resumes);
return_value = eExecutionSetupError;
break;
}
stop_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (stop_state != eStateRunning)
{
bool restarted = false;
if (stop_state == eStateStopped)
{
restarted = Process::ProcessEventData::GetRestartedFromEvent(event_sp.get());
if (log)
log->Printf("Process::RunThreadPlan(): didn't get running event after "
"resume %d, got %s instead (restarted: %i, do_resume: %i, handle_running_event: %i).",
num_resumes,
StateAsCString(stop_state),
restarted,
do_resume,
handle_running_event);
}
if (restarted)
{
// This is probably an overabundance of caution, I don't think I should ever get a stopped & restarted
// event here. But if I do, the best thing is to Halt and then get out of here.
Halt();
}
errors.Printf("Didn't get running event after initial resume, got %s instead.",
StateAsCString(stop_state));
return_value = eExecutionSetupError;
break;
}
if (log)
log->PutCString ("Process::RunThreadPlan(): resuming succeeded.");
// We need to call the function synchronously, so spin waiting for it to return.
// If we get interrupted while executing, we're going to lose our context, and
// won't be able to gather the result at this point.
// We set the timeout AFTER the resume, since the resume takes some time and we
// don't want to charge that to the timeout.
}
else
{
if (log)
log->PutCString ("Process::RunThreadPlan(): waiting for next event.");
}
if (before_first_timeout)
{
if (options.GetTryAllThreads())
timeout_ptr = &one_thread_timeout;
else
{
if (timeout_usec == 0)
timeout_ptr = NULL;
else
timeout_ptr = &final_timeout;
}
}
else
{
if (timeout_usec == 0)
timeout_ptr = NULL;
else
timeout_ptr = &final_timeout;
}
do_resume = true;
handle_running_event = true;
// Now wait for the process to stop again:
event_sp.reset();
if (log)
{
if (timeout_ptr)
{
log->Printf ("Process::RunThreadPlan(): about to wait - now is %" PRIu64 " - endpoint is %" PRIu64,
TimeValue::Now().GetAsMicroSecondsSinceJan1_1970(),
timeout_ptr->GetAsMicroSecondsSinceJan1_1970());
}
else
{
log->Printf ("Process::RunThreadPlan(): about to wait forever.");
}
}
got_event = listener.WaitForEvent (timeout_ptr, event_sp);
if (got_event)
{
if (event_sp.get())
{
bool keep_going = false;
if (event_sp->GetType() == eBroadcastBitInterrupt)
{
Halt();
return_value = eExecutionInterrupted;
errors.Printf ("Execution halted by user interrupt.");
if (log)
log->Printf ("Process::RunThreadPlan(): Got interrupted by eBroadcastBitInterrupted, exiting.");
break;
}
else
{
stop_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (log)
log->Printf("Process::RunThreadPlan(): in while loop, got event: %s.", StateAsCString(stop_state));
switch (stop_state)
{
case lldb::eStateStopped:
{
// We stopped, figure out what we are going to do now.
ThreadSP thread_sp = GetThreadList().FindThreadByIndexID (thread_idx_id);
if (!thread_sp)
{
// Ooh, our thread has vanished. Unlikely that this was successful execution...
if (log)
log->Printf ("Process::RunThreadPlan(): execution completed but our thread (index-id=%u) has vanished.", thread_idx_id);
return_value = eExecutionInterrupted;
}
else
{
// If we were restarted, we just need to go back up to fetch another event.
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
{
if (log)
{
log->Printf ("Process::RunThreadPlan(): Got a stop and restart, so we'll continue waiting.");
}
keep_going = true;
do_resume = false;
handle_running_event = true;
}
else
{
StopInfoSP stop_info_sp (thread_sp->GetStopInfo ());
StopReason stop_reason = eStopReasonInvalid;
if (stop_info_sp)
stop_reason = stop_info_sp->GetStopReason();
// FIXME: We only check if the stop reason is plan complete, should we make sure that
// it is OUR plan that is complete?
if (stop_reason == eStopReasonPlanComplete)
{
if (log)
log->PutCString ("Process::RunThreadPlan(): execution completed successfully.");
// Now mark this plan as private so it doesn't get reported as the stop reason
// after this point.
if (thread_plan_sp)
thread_plan_sp->SetPrivate (orig_plan_private);
return_value = eExecutionCompleted;
}
else
{
// Something restarted the target, so just wait for it to stop for real.
if (stop_reason == eStopReasonBreakpoint)
{
if (log)
log->Printf ("Process::RunThreadPlan() stopped for breakpoint: %s.", stop_info_sp->GetDescription());
return_value = eExecutionHitBreakpoint;
if (!options.DoesIgnoreBreakpoints())
{
event_to_broadcast_sp = event_sp;
}
}
else
{
if (log)
log->PutCString ("Process::RunThreadPlan(): thread plan didn't successfully complete.");
if (!options.DoesUnwindOnError())
event_to_broadcast_sp = event_sp;
return_value = eExecutionInterrupted;
}
}
}
}
}
break;
case lldb::eStateRunning:
// This shouldn't really happen, but sometimes we do get two running events without an
// intervening stop, and in that case we should just go back to waiting for the stop.
do_resume = false;
keep_going = true;
handle_running_event = false;
break;
default:
if (log)
log->Printf("Process::RunThreadPlan(): execution stopped with unexpected state: %s.", StateAsCString(stop_state));
if (stop_state == eStateExited)
event_to_broadcast_sp = event_sp;
errors.Printf ("Execution stopped with unexpected state.\n");
return_value = eExecutionInterrupted;
break;
}
}
if (keep_going)
continue;
else
break;
}
else
{
if (log)
log->PutCString ("Process::RunThreadPlan(): got_event was true, but the event pointer was null. How odd...");
return_value = eExecutionInterrupted;
break;
}
}
else
{
// If we didn't get an event that means we've timed out...
// We will interrupt the process here. Depending on what we were asked to do we will
// either exit, or try with all threads running for the same timeout.
if (log) {
if (options.GetTryAllThreads())
{
uint64_t remaining_time = final_timeout - TimeValue::Now();
if (before_first_timeout)
log->Printf ("Process::RunThreadPlan(): Running function with one thread timeout timed out, "
"running till for %" PRIu64 " usec with all threads enabled.",
remaining_time);
else
log->Printf ("Process::RunThreadPlan(): Restarting function with all threads enabled "
"and timeout: %u timed out, abandoning execution.",
timeout_usec);
}
else
log->Printf ("Process::RunThreadPlan(): Running function with timeout: %u timed out, "
"abandoning execution.",
timeout_usec);
}
// It is possible that between the time we issued the Halt, and we get around to calling Halt the target
// could have stopped. That's fine, Halt will figure that out and send the appropriate Stopped event.
// BUT it is also possible that we stopped & restarted (e.g. hit a signal with "stop" set to false.) In
// that case, we'll get the stopped & restarted event, and we should go back to waiting for the Halt's
// stopped event. That's what this while loop does.
bool back_to_top = true;
uint32_t try_halt_again = 0;
bool do_halt = true;
const uint32_t num_retries = 5;
while (try_halt_again < num_retries)
{
Error halt_error;
if (do_halt)
{
if (log)
log->Printf ("Process::RunThreadPlan(): Running Halt.");
halt_error = Halt();
}
if (halt_error.Success())
{
if (log)
log->PutCString ("Process::RunThreadPlan(): Halt succeeded.");
real_timeout = TimeValue::Now();
real_timeout.OffsetWithMicroSeconds(500000);
got_event = listener.WaitForEvent(&real_timeout, event_sp);
if (got_event)
{
stop_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (log)
{
log->Printf ("Process::RunThreadPlan(): Stopped with event: %s", StateAsCString(stop_state));
if (stop_state == lldb::eStateStopped
&& Process::ProcessEventData::GetInterruptedFromEvent(event_sp.get()))
log->PutCString (" Event was the Halt interruption event.");
}
if (stop_state == lldb::eStateStopped)
{
// Between the time we initiated the Halt and the time we delivered it, the process could have
// already finished its job. Check that here:
if (thread->IsThreadPlanDone (thread_plan_sp.get()))
{
if (log)
log->PutCString ("Process::RunThreadPlan(): Even though we timed out, the call plan was done. "
"Exiting wait loop.");
return_value = eExecutionCompleted;
back_to_top = false;
break;
}
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
{
if (log)
log->PutCString ("Process::RunThreadPlan(): Went to halt but got a restarted event, there must be an un-restarted stopped event so try again... "
"Exiting wait loop.");
try_halt_again++;
do_halt = false;
continue;
}
if (!options.GetTryAllThreads())
{
if (log)
log->PutCString ("Process::RunThreadPlan(): try_all_threads was false, we stopped so now we're quitting.");
return_value = eExecutionInterrupted;
back_to_top = false;
break;
}
if (before_first_timeout)
{
// Set all the other threads to run, and return to the top of the loop, which will continue;
before_first_timeout = false;
thread_plan_sp->SetStopOthers (false);
if (log)
log->PutCString ("Process::RunThreadPlan(): about to resume.");
back_to_top = true;
break;
}
else
{
// Running all threads failed, so return Interrupted.
if (log)
log->PutCString("Process::RunThreadPlan(): running all threads timed out.");
return_value = eExecutionInterrupted;
back_to_top = false;
break;
}
}
}
else
{ if (log)
log->PutCString("Process::RunThreadPlan(): halt said it succeeded, but I got no event. "
"I'm getting out of here passing Interrupted.");
return_value = eExecutionInterrupted;
back_to_top = false;
break;
}
}
else
{
try_halt_again++;
continue;
}
}
if (!back_to_top || try_halt_again > num_retries)
break;
else
continue;
}
} // END WAIT LOOP
// If we had to start up a temporary private state thread to run this thread plan, shut it down now.
if (IS_VALID_LLDB_HOST_THREAD(backup_private_state_thread))
{
StopPrivateStateThread();
Error error;
m_private_state_thread = backup_private_state_thread;
if (stopper_base_plan_sp)
{
thread->DiscardThreadPlansUpToPlan(stopper_base_plan_sp);
}
m_public_state.SetValueNoLock(old_state);
}
// Restore the thread state if we are going to discard the plan execution. There are three cases where this
// could happen:
// 1) The execution successfully completed
// 2) We hit a breakpoint, and ignore_breakpoints was true
// 3) We got some other error, and discard_on_error was true
bool should_unwind = (return_value == eExecutionInterrupted && options.DoesUnwindOnError())
|| (return_value == eExecutionHitBreakpoint && options.DoesIgnoreBreakpoints());
if (return_value == eExecutionCompleted
|| should_unwind)
{
thread_plan_sp->RestoreThreadState();
}
// Now do some processing on the results of the run:
if (return_value == eExecutionInterrupted || return_value == eExecutionHitBreakpoint)
{
if (log)
{
StreamString s;
if (event_sp)
event_sp->Dump (&s);
else
{
log->PutCString ("Process::RunThreadPlan(): Stop event that interrupted us is NULL.");
}
StreamString ts;
const char *event_explanation = NULL;
do
{
if (!event_sp)
{
event_explanation = "<no event>";
break;
}
else if (event_sp->GetType() == eBroadcastBitInterrupt)
{
event_explanation = "<user interrupt>";
break;
}
else
{
const Process::ProcessEventData *event_data = Process::ProcessEventData::GetEventDataFromEvent (event_sp.get());
if (!event_data)
{
event_explanation = "<no event data>";
break;
}
Process *process = event_data->GetProcessSP().get();
if (!process)
{
event_explanation = "<no process>";
break;
}
ThreadList &thread_list = process->GetThreadList();
uint32_t num_threads = thread_list.GetSize();
uint32_t thread_index;
ts.Printf("<%u threads> ", num_threads);
for (thread_index = 0;
thread_index < num_threads;
++thread_index)
{
Thread *thread = thread_list.GetThreadAtIndex(thread_index).get();
if (!thread)
{
ts.Printf("<?> ");
continue;
}
ts.Printf("<0x%4.4" PRIx64 " ", thread->GetID());
RegisterContext *register_context = thread->GetRegisterContext().get();
if (register_context)
ts.Printf("[ip 0x%" PRIx64 "] ", register_context->GetPC());
else
ts.Printf("[ip unknown] ");
lldb::StopInfoSP stop_info_sp = thread->GetStopInfo();
if (stop_info_sp)
{
const char *stop_desc = stop_info_sp->GetDescription();
if (stop_desc)
ts.PutCString (stop_desc);
}
ts.Printf(">");
}
event_explanation = ts.GetData();
}
} while (0);
if (event_explanation)
log->Printf("Process::RunThreadPlan(): execution interrupted: %s %s", s.GetData(), event_explanation);
else
log->Printf("Process::RunThreadPlan(): execution interrupted: %s", s.GetData());
}
if (should_unwind)
{
if (log)
log->Printf ("Process::RunThreadPlan: ExecutionInterrupted - discarding thread plans up to %p.", thread_plan_sp.get());
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
thread_plan_sp->SetPrivate (orig_plan_private);
}
else
{
if (log)
log->Printf ("Process::RunThreadPlan: ExecutionInterrupted - for plan: %p not discarding.", thread_plan_sp.get());
}
}
else if (return_value == eExecutionSetupError)
{
if (log)
log->PutCString("Process::RunThreadPlan(): execution set up error.");
if (options.DoesUnwindOnError())
{
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
thread_plan_sp->SetPrivate (orig_plan_private);
}
}
else
{
if (thread->IsThreadPlanDone (thread_plan_sp.get()))
{
if (log)
log->PutCString("Process::RunThreadPlan(): thread plan is done");
return_value = eExecutionCompleted;
}
else if (thread->WasThreadPlanDiscarded (thread_plan_sp.get()))
{
if (log)
log->PutCString("Process::RunThreadPlan(): thread plan was discarded");
return_value = eExecutionDiscarded;
}
else
{
if (log)
log->PutCString("Process::RunThreadPlan(): thread plan stopped in mid course");
if (options.DoesUnwindOnError() && thread_plan_sp)
{
if (log)
log->PutCString("Process::RunThreadPlan(): discarding thread plan 'cause unwind_on_error is set.");
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
thread_plan_sp->SetPrivate (orig_plan_private);
}
}
}
// Thread we ran the function in may have gone away because we ran the target
// Check that it's still there, and if it is put it back in the context. Also restore the
// frame in the context if it is still present.
thread = GetThreadList().FindThreadByIndexID(thread_idx_id, true).get();
if (thread)
{
exe_ctx.SetFrameSP (thread->GetFrameWithStackID (ctx_frame_id));
}
// Also restore the current process'es selected frame & thread, since this function calling may
// be done behind the user's back.
if (selected_tid != LLDB_INVALID_THREAD_ID)
{
if (GetThreadList().SetSelectedThreadByIndexID (selected_tid) && selected_stack_id.IsValid())
{
// We were able to restore the selected thread, now restore the frame:
Mutex::Locker lock(GetThreadList().GetMutex());
StackFrameSP old_frame_sp = GetThreadList().GetSelectedThread()->GetFrameWithStackID(selected_stack_id);
if (old_frame_sp)
GetThreadList().GetSelectedThread()->SetSelectedFrame(old_frame_sp.get());
}
}
}
// If the process exited during the run of the thread plan, notify everyone.
if (event_to_broadcast_sp)
{
if (log)
log->PutCString("Process::RunThreadPlan(): rebroadcasting event.");
BroadcastEvent(event_to_broadcast_sp);
}
return return_value;
}
const char *
Process::ExecutionResultAsCString (ExecutionResults result)
{
const char *result_name;
switch (result)
{
case eExecutionCompleted:
result_name = "eExecutionCompleted";
break;
case eExecutionDiscarded:
result_name = "eExecutionDiscarded";
break;
case eExecutionInterrupted:
result_name = "eExecutionInterrupted";
break;
case eExecutionHitBreakpoint:
result_name = "eExecutionHitBreakpoint";
break;
case eExecutionSetupError:
result_name = "eExecutionSetupError";
break;
case eExecutionTimedOut:
result_name = "eExecutionTimedOut";
break;
case eExecutionStoppedForDebug:
result_name = "eExecutionStoppedForDebug";
break;
}
return result_name;
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
void
Process::GetStatus (Stream &strm)
{
const StateType state = GetState();
if (StateIsStoppedState(state, false))
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
if (state == eStateExited)
{
int exit_status = GetExitStatus();
const char *exit_description = GetExitDescription();
strm.Printf ("Process %" PRIu64 " exited with status = %i (0x%8.8x) %s\n",
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
GetID(),
exit_status,
exit_status,
exit_description ? exit_description : "");
}
else
{
if (state == eStateConnected)
strm.Printf ("Connected to remote target.\n");
else
strm.Printf ("Process %" PRIu64 " %s\n", GetID(), StateAsCString (state));
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
}
else
{
strm.Printf ("Process %" PRIu64 " is running.\n", GetID());
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
}
size_t
Process::GetThreadStatus (Stream &strm,
bool only_threads_with_stop_reason,
uint32_t start_frame,
uint32_t num_frames,
uint32_t num_frames_with_source)
{
size_t num_thread_infos_dumped = 0;
// You can't hold the thread list lock while calling Thread::GetStatus. That very well might run code (e.g. if we need it
// to get return values or arguments.) For that to work the process has to be able to acquire it. So instead copy the thread
// ID's, and look them up one by one:
uint32_t num_threads;
std::vector<uint32_t> thread_index_array;
//Scope for thread list locker;
{
Mutex::Locker locker (GetThreadList().GetMutex());
ThreadList &curr_thread_list = GetThreadList();
num_threads = curr_thread_list.GetSize();
uint32_t idx;
thread_index_array.resize(num_threads);
for (idx = 0; idx < num_threads; ++idx)
thread_index_array[idx] = curr_thread_list.GetThreadAtIndex(idx)->GetID();
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
for (uint32_t i = 0; i < num_threads; i++)
{
ThreadSP thread_sp(GetThreadList().FindThreadByID(thread_index_array[i]));
if (thread_sp)
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
if (only_threads_with_stop_reason)
{
StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
if (stop_info_sp.get() == NULL || !stop_info_sp->IsValid())
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
continue;
}
thread_sp->GetStatus (strm,
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
start_frame,
num_frames,
num_frames_with_source);
++num_thread_infos_dumped;
}
else
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::GetThreadStatus - thread 0x" PRIu64 " vanished while running Thread::GetStatus.");
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
return num_thread_infos_dumped;
}
void
Process::AddInvalidMemoryRegion (const LoadRange &region)
{
m_memory_cache.AddInvalidRange(region.GetRangeBase(), region.GetByteSize());
}
bool
Process::RemoveInvalidMemoryRange (const LoadRange &region)
{
return m_memory_cache.RemoveInvalidRange(region.GetRangeBase(), region.GetByteSize());
}
void
Process::AddPreResumeAction (PreResumeActionCallback callback, void *baton)
{
m_pre_resume_actions.push_back(PreResumeCallbackAndBaton (callback, baton));
}
bool
Process::RunPreResumeActions ()
{
bool result = true;
while (!m_pre_resume_actions.empty())
{
struct PreResumeCallbackAndBaton action = m_pre_resume_actions.back();
m_pre_resume_actions.pop_back();
bool this_result = action.callback (action.baton);
if (result == true) result = this_result;
}
return result;
}
void
Process::ClearPreResumeActions ()
{
m_pre_resume_actions.clear();
}
void
Process::Flush ()
{
m_thread_list.Flush();
m_extended_thread_list.Flush();
m_extended_thread_stop_id = 0;
m_queue_list.Clear();
m_queue_list_stop_id = 0;
}
void
Process::DidExec ()
{
Target &target = GetTarget();
target.CleanupProcess ();
target.ClearModules(false);
m_dynamic_checkers_ap.reset();
m_abi_sp.reset();
m_system_runtime_ap.reset();
m_os_ap.reset();
m_dyld_ap.reset();
m_jit_loaders_ap.reset();
m_image_tokens.clear();
m_allocated_memory_cache.Clear();
m_language_runtimes.clear();
m_thread_list.DiscardThreadPlans();
m_memory_cache.Clear(true);
DoDidExec();
CompleteAttach ();
// Flush the process (threads and all stack frames) after running CompleteAttach()
// in case the dynamic loader loaded things in new locations.
Flush();
// After we figure out what was loaded/unloaded in CompleteAttach,
// we need to let the target know so it can do any cleanup it needs to.
target.DidExec();
}
addr_t
Process::ResolveIndirectFunction(const Address *address, Error &error)
{
if (address == nullptr)
{
error.SetErrorString("Invalid address argument");
return LLDB_INVALID_ADDRESS;
}
addr_t function_addr = LLDB_INVALID_ADDRESS;
addr_t addr = address->GetLoadAddress(&GetTarget());
std::map<addr_t,addr_t>::const_iterator iter = m_resolved_indirect_addresses.find(addr);
if (iter != m_resolved_indirect_addresses.end())
{
function_addr = (*iter).second;
}
else
{
if (!InferiorCall(this, address, function_addr))
{
Symbol *symbol = address->CalculateSymbolContextSymbol();
error.SetErrorStringWithFormat ("Unable to call resolver for indirect function %s",
symbol ? symbol->GetName().AsCString() : "<UNKNOWN>");
function_addr = LLDB_INVALID_ADDRESS;
}
else
{
m_resolved_indirect_addresses.insert(std::pair<addr_t, addr_t>(addr, function_addr));
}
}
return function_addr;
}
void
Process::ModulesDidLoad (ModuleList &module_list)
{
SystemRuntime *sys_runtime = GetSystemRuntime();
if (sys_runtime)
{
sys_runtime->ModulesDidLoad (module_list);
}
GetJITLoaders().ModulesDidLoad (module_list);
}